Seven Levels of Coupling: Seven Deadly Sins or Seventh Heaven?

In this posting I discuss the Zapthink article by Ronald Schmelzer, "The Seven Levels of Loose Coupling".

This week I have found two commentators redefining loose coupling. The first is described in the discussion about virtual endpoints that was the subject of my previous posting and the second was this Zapthink article. I think it is important we clarify our definitions around SOA to avoid the concept being hijacked by commercial interests. So in this posting and the last I have attempted to sort out whether the discussion is adding to our understanding or muddying the waters.

In a previous posting I have identified 18 different types of coupling and I am still finding more. The first thing to realise about the seven levels of coupling is they are looking at a different attribute of coupling than what I refer to as 'types of coupling'. The levels refer to the entities that are being coupled. My discussion on coupling types looks at the coupling of two modules of program code. This code could be in calling programs, objects, subroutines or services.

The following table lists the seven levels. This table makes the distinction between 'Levels of Coupling' and 'Types of Coupling' clear. The core tenet that Zapthink is discussing is the "loose coupling of Service consumers and providers". This has a different meaning than loose coupling between program code in different services. The main difference is that aspects of the service provider, with the exception of the implementation are not program code at all. Another difference is that a service consumer may not be a service either and it also might not contain program code.

	Aspects of the Service Provider	Possible Types of Coupling
Loose Coupling the Implementation	The service implementation	18 types and still counting
Loose Coupling the Service Contract	Service contract	Interface Coupling, Bind-Time Coupling, Service Intermediary Coupling, Infrastructure configuration Coupling
Loose Coupling the Service Policy	Service policy	Bind-Time Coupling, Service Intermediary Coupling, Infrastructure configuration Coupling
Loose Coupling the Process	Service-oriented process (Trivial if this is a service)	18 types and still counting
Loose Coupling the Data Schema	Data schema of provider dataset and data schema of interface.	Data Services Layer Coupling, Data Transformation Service Coupling
Loose Coupling the Infrastructure	Infrastructure of provider	Single-vendor SOA platform Coupling
Loose Coupling at the Semantic Layer	Meaning of message attributes	Dynamic service definition Coupling

The seven layers are not as clearly layered as the phrase 'Levels' might suggest. Certainly policies could be considered a higher level than contracts and processes considered at higher level to implementation. The other levels could be considered to sit atop the infrastructure level and under the semantic level but normally data and process would sit beside each other with neither the master. I also see contracts sitting beside data and process as equal partners.

Coupling takes account of the dependency between two entities and the clarity of this dependency. Thus two services exchanging a message are loosely coupled if every dependency is clear from the format of the message. Services have different reasons for being dependent. These reasons are what we mean by 'Types of coupling'.

The types of coupling for the seven levels are described in the third column of table above. The first level describes service to service coupling which I have described earlier. The fourth level is interesting because the solution is almost trivial. The business process should look like a service and therefore all the coupling types for coupling between services also apply for coupling between a consumer service and provider service that is a composition of services used to implement a process. The sort of things that might cause dependencies with contacts, polices, infrastructure, data schemas and semantics are different to the program code dependencies.

Loose coupling of data schema is partly addressed by another Zapthink article which advocates the building of data transformation services rather than incorporating transformation logic inside services used to contain business logic.

Tight coupling between the consumer service and the infrastructure of the provider could be based around a number of proprietary technologies. The ones highlighted by Zapthink are the non-standard ESB and the single vendor SOA platform.

The types listed in the third column of the above table are those implied in the Zapthink article. I expect that a thorough investigation would uncover other types of coupling as well. The point of listing them in the table is to suggest that each coupling level will have its own types and each level (with the possible exception of the process level) needs to be investigated separately.

We can find coupling examples everywhere. For example Carlos Perez and David Walend discuss whether a DBMS and its application are loosely coupled if the application is accessing the DBMS using SQL. This is interesting but not relevant to SOA. For the point of view of defining SOA, I do not believe the seven levels of loose coupling matter. You can have an SOA as long as the services are loosely coupled. However as a model to assist good practice, I think the seven levels will provide value even if they do overload the 'loose coupling' term.

The concepts discussed in relation to levels of coupling are certainly valid. We do not want service consumers dying or behaving incorrectly due to changes with service provider's infrastructure, policies or any of the other aspects described in the seven levels. Zapthink continue to guide us on the path to software heaven, however in the process of introducing 'levels of coupling' Zapthink commit the sin of causing confusion around the important 'loose coupling' term. I recommend the "Seven Levels" article to SOA developers and I suggest developers need to be clear on what is being coupled whenever they use or encounter the term 'loose coupling'.

End Note:
One way to distinguish other levels of coupling from service to service implementation coupling would be to call the different levels something different other than 'loose coupling'. The names that occurred to me were 'loose buckling' or even 'loose zipping' which would be reminiscent of the zapthink integration zipper. Unfortunately both these terms have implications of embarrassing failure if the buckling or zipping is too loose. We do not want our metaphorical trousers around our ankles.

Is Your Enterprise Architecture SOA Compliant?

In August I wrote about the Zachman framework and SOA. This was the basis for a couple more slides at the Ark Group conference on interoperability in which I was a presenter. I have covered material from the presentation in couple for previous postings, "Live up to the Legacy that was Left" and "Why SOA?". I will focus on the main theme of my presentation in this posting which was "Ensuring your Enterprise Architecture is SOA Compliant"

Firstly I would like to point out some work that is being done by the SOA Consortium along these lines. They have announced the Enterprise Architecture 2010 Working Group which is to define the high-level roles and deliverables of the Enterprise Architecture team. There is not much tangible yet from this group as it has just been set up but these people also brought us the SOA practitioners' guides so this could prove a valuable initiative.

At the conference mention in the first paragraph I went over the Zachman Framework as I have done in my earlier posting. One thing I pointed out is that different software development approaches can be described in terms of the framework. I then went on a described my organisations use of the Zachman framework using he colour codes I added to the Zachman grid.

When we talk about top-down approaches conveniently you work from the top row (Scope Row) down to the bottom row (Detailed Representation). Similarly when you work bottom-up you work from the bottom of the framework representation.

Assuming that most good software development is done top-down (and I am subscriber to this approach) you can choose different methodologies depending on the column you choose.

If you drive down the 'Data' column you have a Data Driven Architecture. The Enterprise Information Model in this approach is all important. The other cells of the framework will either support the data column or be influenced by it.

The SOA approach is usually focused on business process and this means it is being driven by the 'Function' column. Software development can be driven from Business Process Modelling and 'Function' column without being SOA.

If we are two focused driving our software development from the 'Network' column we may end up with a siloed application based on organisational locations. This generally software development anti-pattern as modern enterprise software should be independent of location.

Similarly, too much focus on the 'People' column can lead to application focussing around individual or organisational units. This is a very common siloed approach and anti-pattern. More positively a people driven architecture will look at the user experience. This is a common approach for smaller applications to look at screen designs, report layouts and user interaction scenarios that will meet user requirements. For enterprise application though it is important to look at the bigger picture, to question what the organisation is trying to achieve and to model the process from start to finish otherwise the people siloed anti-pattern may result.

If we drive down the 'Time' column we will end up with an Event Driven Architecture (EDA). This is an alternate approach to SOA. We look at events and how they initiate and affect business processes. The 'Function' columns and 'Time' columns can be worked with in tandem to produce and event driven SOA application.

If we work down the 'Motivation' column of the Zachman frame work then we are using a Business Rules Approach. My organisation has not made great use of this framework column. For more information about the Business Rules Approach see http://www.businessrulesgroup.org/ . Also this column is valuable for expert systems and decision management.

With the Zachman framework you do not have to fill every cell. You certainly do not only have one enterprise model in each cell. How you uses the Zachman framework is important. So I will describe how our organisation uses it in terms of the diagram above.

The yellow cells in the above diagram are areas where we have not got any significant documentation.

The green cells contain documentation the business has prepared with out prodding from the IT department. The brown cells are documented by IT but with the interaction of the business.

The top two layers do not change much. These are business level documents. Producing good business process models is more important with SOA. The business process is the key in the SOA process not the application.

The blue is driven by SOA. It starts with your Application Architecture. Distributed Architecture works differently with SOA. You might consider and ESB for instance which will give a different architecture than if you use point-to-point communication. These upper two blue cells drive changes at the more detail level below them.

The pink areas are affected by SOA. Data modelling and Human interface architecture are not radically different but they have to take into account the new architecture.

I will now look at the link between EA and SOA in a different way.

Zapthink has a good article on Zachman and SOA where they use arrows emanating from the Application Architecture cell of the framework. I prefer to represent the influence direction as predominately down representing a top-down approach.

We will start in the 'Data' column again. I do not think the Information Model should be different as a result of SOA. However the Logical Data Model probably should. It should document the interfaces and be able to transform the representation in XML. It should also document the persistent data stores. You now have at least two levels of logical data modelling.

The physical data model and data definition can then be XML, XSD and WSDL. At the same time you have your modelling of persistent data which would be your normal Class Model or ER diagram. This data model would eventually be represented in data dictionaries and database schemas.

We will move across to the 'Function' column now. The Business Process Model should influence your application architecture. Application Architecture should advise you of what services you need and what services to reuse. A service becomes part of the enterprise architecture because it is built for reuse. A new service is also part of a solution architecture. The service has to meet both solution and enterprise needs. Also in this cell is your application stack which supports the service model. The service model then drives the more detailed System Design and the programming.

SOA is a distributed architecture so the lower rows of the 'Network' column takes on increased significance compared with traditional software development approaches. There is more flexibility about where you do your processing. This needs to be built into your Distributed System Architecture.

Business logistics (and particularly whether you are dealing with agencies external to the organisation) will impact your applications architecture. There is a stronger linkage from Application Architecture to Distributed System Architecture because SOA is an enabling technology. It enables you to distribute processing, to look at load balancing and to look at interfaces with other agencies. There is therefore a strong influence on distributed architecture increasing the importance of good architecture in this space.

As with the other columns the influence downward is strong. Your Technology Architecture and Network Architecture needs to be built to cope with the new Distributed Systems Architecture.

Human interface architecture in the 'People' column may change to suit SOA but it does not have to. Some interface technologies work better with SOA. Some ways of interacting with an application work better with SOA but if you want to drive it the other way by specifying your Human Interface Architecture first then this can also work.
Security Architecture gets its own arrow. It is not a logical progression from Presentation Architecture. You may have to do security differently under SOA. You may have to make better use of a standard infrastructure. You may have to use SOA security standards.

SOA for my organisation is business process driven although there is still some bottom up development resulting from services based on mainframe data entities. The focus on reuse and the question for what we already have available to reuse demands some bottom-up consideration.

To be SOA compliant your architecture needs to include:

• Documented business processes,
• Enough bottom-up analysis to reuse of existing services, and
• Data modeling of web service interfaces.

This is in addition to SOA infrastructure and distributed models required the lower levels of your architecture. SOA is an Enterprise Architecture approach. You cannot have an effective SOA unless you have some level of Enterprise Architecture. If you focus on a single solution or application and do not look at the wider needs of the enterprise then you are going to miss the major benefits of SOA.

The business process focus and implications around reuse mean that the business needs to be aware of the SOA approach. It is a change to business practice that the SOA consortium is looking at in its Enterprise Architecture 2010 Working Group.

Conference Summary Served with Spaghetti

I presented at a conference “Achieving Interoperability in Systems Architecture” on Wednesday. The occasional get together of architects, managers and developers is valuable. You can grab the odd new insight and find new approaches but it is also good to see others attacking problems in the same way and validating your own approaches.

After the conference I thought I would finish this summary on the aeroplane home. I have always wondered how to spend the time on long flights profitably and I admired a couple of passengers using laptops on my previous flight. Unfortunately as I try to use the laptop in flight I am in a middle seat with no elbow room on either side, and now I am served dinner in middle of the flight. I am juggling my laptop and the worst Spaghetti Bolognaise I have ever tasted. Still, here is the summary.

Josh Graham of Thoughtworks kept time well and came up with the comment “Why should I expect straight lines on my Business Process Model when business is inherently messy.” He also introduced one of our New Zealand guests as coming from the land of the “Wrong White Crowd” which sounds like a political comment and spoonerism wrapped up into one.

Mark Murphy of Tower Aust Ltd advocated we start small with SOA. He quoted IDC showing growth in SOA from $3.5bn in 2005 to $33bn estimated in 2010. Mark looked at some SOA definitions and aptly described the current situation where people build silo applications and then expect IT to join them together. He showed a couple of models from Sun and Microsoft showing SOA models that illustrated logical SOA.

Stephen Smith of Arcbok presented a simple framework for assessing the readiness of an organization for SOA. The framework consisted of assessing an organization on the dimensions of Leadership & Culture, Business, Technology, Knowledge, Funding and Sustainability. Each dimension has a number of questions to ask about an organization to asses its readiness. The sustainability dimension described whether the organization had the appropriate support, operations and governance in place for sustain the SOA. This also could include appropriate operational monitoring, measuring and standards. A readiness assessment tool is about risk management. Beware vendor maturity assessments that are used as tools to sell more services.

Krist Davood of AGL and Sensis has achieved something that everyone in the room envied. He had success justified SOA as an initiative using fairly hard-nosed accounting principles. He had justified SOA because of its ability to avoid periodic failures in the business because of the current way of doing things. He had been able cost these failures and justify the project to introduce SOA into the organization. SOA as a strategy to eliminate risk had been demonstrated to be effective.

Centrelink is a huge SOA operation and it was good to hear from Rob Doughty who is their Applications Architect. I liked his characterization of users as “Human Task Delegates” in relation to workflow applications. It was interesting for me to hear about the legacy system challenges that Centrelink have, but also how their portal work in benefiting other government departments. The focus of the talk was the deployment of a portal product which they will be basing all their systems on. I liked the comment that “Portals bring people and process together”. Rob talked about the challenge of working with various IT groups to deliver on a particular pattern of use in relation to the portal. He advocated the use of an “Integration Competency Centre”.

I then presented on Enterprise Architecture and its links to metadata and SOA. Some of this material is already on my posting on SOA Definitions, SOA Metadata and the Zachman Framework. I will elaborate in a future posting.

John Fisher from the NZ Ministry of Education showed us some great business modelling techniques that had found favour with his users. The technique involved Business Element Models, Business Component Models, Business Role Responsibilities and Business Service Models. The models were focussed on producing requirements for widely federated (eg. For 2,700 schools) SOA systems. He introduced the analogy of using power adapter so could use a drill brought in the UK to explain SOA to users.

Jan McConchie of SA Government ICT Services provided an overview of the challenges that she has to bring together the South Australian Government Services to present a common face to the South Australian citizen. This was interesting because the SA Government has established and Office of the CIO and this is showing the desire to coordinate and rationalise government IT activities. As one of the agencies involved, my organisation will be affected by standardisation and IT governance changes. Jan drew on research by Gartner and Saugutuck Technology to explain what SOA meant to her and discussed some initiatives in place for the SA Government.

Chris Howard was from the State Revenue Office of Victoria. Chris focused on risk and SOA and quoted Gartner, advising that it would take 3-4 years before investments in SOA payed off. He discussed a long term plan for legacy transition which was underpinned by full and frank statements about costs, benefits and risks with his business. Chris endorsed ITIL as an enabler of SOA.

Josh ran an interactive session where we discussed the issues of SOA and getting the business on board. It was never clear what you will find when you "turn over rocks" in the analysis process. We discussed what services to build first. It was not always best to do the low risk, high value project first. In the end it might just be business or legislative imperatives that help you make the decision. It was difficult to decide when to do those cross-cutting "hygiene" services.

George Cascales from Integral Energy discussed how he was implementing SOA in an out-sourced environment. He had a small group of architects and had succeeded in being able to develop new applications quickly using reused services. His group focused on standards and governance rather than the actual development. A set of tools and standards would be given to contract developers to develop the services and applications.

Rajat Chopra, the international speaker from Bell Canada provided a good description of how Bell embraced SOA. It was important for Bell to provide common services to serve its various customer channels for selling telecommunication facilities. Rajat provided us with a number of analogies for explaining SOA to management including Lego blocks, a car factory and diet. With diets, you can latch onto gimmicks but in the end it is lifestyle change that makes the difference. This is the same with SOA.

Alex Jouravlev representing the ACS presented twice. Alex’s first presentation was titled Prepare IT and Business for SOA. He traces the origins of SOA back to 1988. He made the point that our business cases do not really engage the business and we need to strive for simple messages using language the business understands to achieve a ‘mental ownership’. Alex supported the model driven architecture approaches but not for the reasons that they were developed. Business requirements should be developed with referencing any ‘system’ and should be modelled with Visual UML Models. Alex noted that several modelling practices that were usually acknowledged as important were often missed. These include Conceptual Business Modelling, Conceptual Data Modelling, Business Object Modelling and producing an Enterprise Ontology.

Later in the day Alex was able to present a model based on CMMI maturity model in an easy-to-understand fashion with the purpose of moving the SOA objective from IT to the business as an organisation obtains more SOA maturity. Alex was able to give us a realistic view of the limitations that would be expected at each level of maturity and provide an insight into how the role of key players like the Enterprise Architect and Business Analyst would change at the various levels.

Ram Kumar was from OASIS and provided an insight into the work of this organisation that is emersed in creating SOA standards. He discussed his role in developing the Justice Sector Information Interchange standard. This was of special interest to me because of my involvement in this sector. Ram emphasised the importance of XML governance and advocated this for successful SOA.

Josh summarised the conference and he may discuss this on his own blog site. Many themes resonated with me but one stands out as I wrestle with my in-flight dinner. We had slides from at least three of the speakers that showed insanely complicated maps of their existing systems. It seems we are all lumbered with integration spaghetti and our hope is that SOA will resolve this.

SOA and So Much Metadata

Everyone probably knows that metadata is "data about data". This concept has been around throughout the short history of information technology and before. The library catalogue is the archetypal embodiment of metadata. Data structures and then databases need description and these were more technical type declarations, schemas and Entity-Relationship diagrams. XML deserves special mention in this one paragraph of metadata history as it has revolutionised the way metadata is done. Now those library catalogues, those data structures alike can be described in XML.

Now metadata and XML has a particularly important role in SOA. Metadata is the glue that holds services together in SOA. WSDL and SOAP which are both based on XML are used at runtime to communicate with services. This is not the only importance of metadata in SOA though. Metadata has an increasing role during design time if you are going to get the most reusability from your SOA.

The amount of metadata require at design time is huge. To appreciate this it is instructive to have a look at the Zachman architecture framework grid. This 30 cell grid is full of architectures that use metadata models. Some might argue that some of the material from the top rows of the Zachman grid (scope and business model) is pretty far removed from working systems and should not be bundled in with metadata more directly relevant to implemented systems. Program code might not be considered by some as metadata but nevertheless it is an abstraction of data submitted to a CPU for execution. The point is that there is an awful lot of design time metadata in enterprise architecture. It might be XML, or UML, or other diagrams or lists but it should all be recorded and it all is interrelated.

The challenge has always been to store this metadata in a way that allows it to be easily retrieved, in a way that makes the connections to other metadata explicit and a way that can be discovered for new projects. Reusability has not been something that was discovered with SOA. Business process and data models have always been relevant over multiple projects and it has always been important to be able to find metadata when the need arises or when maintenance work needs to be done on old applications.

Finding a repository for all this metadata is not easy. Where these artefacts are stored with the tools that create them it makes it difficult to combine into cohesive store of information. Taking my organisation as an example, we use Telelogic System Architect for the higher level enterprise architecture document and Rational Software Architect for some of models used in our applications. We also have and issue register, a call logging system and diagrams done in Microsoft Visio. For data warehouse we use Oracle Designer and Oracle Data Warehouse builder. We store system information in CVS (software and document versioning), our file server, our intranet and our Wiki. No wonder we sometimes have trouble finding something.

How can I be sure that a developer has looked up all the previous work that has been done previously before the developer proceeds to develop a new service or interface? We could buy a metadata repository to hold all this information, but without good governance of the process of creating metadata this would be just one more data store in which to hide our artefacts. If it is clear what goes where then multiple repositories is not such a problem although it is obviously easier, the fewer different repositories you have.

In a sequel to this posting I will write more about registries and repositories, which are technical aids to solving the metadata flood. In this posting I hope I have established a need for dealing with metadata effectively.

Putting a Face to SOA

There seems to be some things missing from much of the discussion on SOA. In a couple of books I've read SOA as touted as an all-encompassing approach to developing systems but issues on data modelling and user interface are almost completely ignored. These are pretty fundamental parts of or software. Early computer systems were nothing but user interface and database. Now there is so much in between such as business logic and middleware that this all needs to be regarded as the most important part of the architecture. So are there recommendations about how to do the data model and user interface in SOA?

Firstly, does SOA affect the logical data model compared with traditional architectures? My answer is that the method of obtaining the data model may be different but I'm not sure whether the resulting data model is any different from traditional methods. The focus has to be on the message format if the development is to be driven WSDL first. I will probably expand on this in later post but for now I will focus on the user interface for the rest of this post.

The book Service-Oriented Architecture: Concepts, Technology, and Design by Thomas Erl provides good description of SOA and web services but the issue of user interface is never broached. The reader is left to wonder whether the user interface is somehow built into the services or sits outside it. Another book Enterprise SOA: Service-Oriented Architecture Best Practices by Dirk Krafzig, Karl Banke and Dirk Slama explicitly states that the user interface sit outside the service. An article by some IBM authors provides both scenarios. They observe that " The Model-View-Controller (MVC) paradigm underlies most modern UI application frameworks. SOA operations provide the model layer, and UIs occupy the view layer". (Hepper et al)

The IBM article discusses Web Services for Remote Portlet (WSRP) to enable a portal to aggregate content from multiple sources. The intention of WSRP is so that "Content and application provider services can be discovered and plugged into standards-compliant applications without any extra programming effort". This described more succinctly in another article "A remote portlet is a portlet that's deployed in a different environment than the portal that actually uses it" (Ort). The approach assumes the software developer has a portal for the portlet deployment.

The IBM article also looks at the human workflow. If all human interactions can be managed by forms within a workflow product then programmatic user interfaces could presumably disappear. The human workflow is included in the BPEL process designed to orchestrate the SOA. This may be good for simple forms but this is not going to suit all purposes.

There seems to be a weight of industry acceptance behind Rich Internet Applications in general and AJAX in particular. This user interface for SOA uses makes good use of the XML used in web services messages uses asynchronous messaging and is sufficient rich to provide users all they need from a simple web browser. This approach seems to be supported by Zapthink, Tibco and Oracle.

A number of products seem to be appearing that target the SOA user interface space. BEA systems, Sun Microsystems, CapeClear Software, Tibco (see footnote) all plan to add Ajax tools to their SOA-centric products (Meehan). Other solutions will also become evident from vendors like Corizon that use approaches to SOA user interfaces that differ to the AJAX approach.

The combination of AJAX and WSRP seems well accepted by the industry. "These two technologies complement each other in terms of ease of sharing of aggregated content and better usability of such content" (Padmanabhuni et al). AJAX support will be included in WSRP version 3 (Dovey). These technologies have been included in both the IBM Websphere and BEA Weblogic portal products. AJAX allows the interfaces with sufficient richness to be developed for Web Service applications and WSRP allows interfaces to be deployed and aggregated into portals easily.

It looks like the choice to use SOA and the choice over interface technology will always remain fairly independent although not unconnected. This could be an advantage as it will mean that that good user interface technology can develop reasonably independently for the evolving web services standards. A portal seems a generally accepted starting point for an SOA user interface. AJAX and WSRP are popular technologies to take advantage of web services. The human workflow approach as way for users to interact with SOA is worth watching. This will be an effective way to build workflow applications that have simple form-based user interfaces.

Footnote
Comments received on this blog suggest that Tibco have already released Ajax tools for their SOA product offering.

References
Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004

Hepper, S, Liesche, S and Stockton, M, http://www.ibm.com/developerworks/library/ws-soa-progmodel5/index.html

Ort, Ed, What's New in SOA and Web Services? http://java.sun.com/developer/technicalArticles/WebServices/soa2/WhatsNewArticle.html

Meehan, Michael, Vendors look to Ajax to make SOA shine
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1144429,00.html

Padmanabhuni, S, Kunti, K, Sahoo, L and Bharti, S, Coupling RDF/RSS, WSRP and AJAX for Dynamic Reusable Portlets: An Approach and a Use Case, http://doi.ieeecomputersociety.org/10.1109/SERVICES.2007.26

Dovey, Matthew, WSRP2 and JSR286,
http://www.nesc.ac.uk/talks/686/10-00_Dovey-WSRP2-JSR286.ppt

Seeley, Rich, Ajax tools from IBM and real-time Java for SOA from BEA,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1213063,00.html

Seeley, Rich, BEA bets its portal on WSRP, Ajax,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1198691,00.html

Davies, David, SOA at the user interface, http://www.looselycoupled.com/opinion/2006/davies-ui-dev0424.html

Tibco, Rich Portals: The Ideal User Interface for SOA,
http://www.tibco.com/resources/mk/rich_portals.pdf

Bloomberg, Jason, Corizon: Leveraging User Interface Services for Rapid Application Creation
http://www.zapthink.com/report.html?id=ZTZN-1216

Hype Cycle for Application Development

I recently read an article from Gartner Research (Hype Cycle for Application Development, ID Number G00147982). Generally I find the material from Gartner great. It's reasonably independent and provides the right level of detail for me mostly. It costs alot to access so you have to find an employer or university to part with the cash to subscribe. I recently heard from a vendor of mapping software that said Gartner wanted $40k to do a review of their software and include them in an appropriate "Magic Quadrant". So their independence is not absolute.

The "Hype Cycle" article was a good summary of what is happening in software development today and the relative maturity of a number of technologies, concepts and product sets. It was handy to brush up on some acronyms. ARAD SODA apparently means Architected Rapid Application Development Services-Oriented Development of Application. You can also have Architected, Model-Driven SODA. Now that seems to be putting all the current buzzwords together in a couple of long acronyms. When did 'architect' become a verb? Any way now I know that what I am trying to do at work is a SODA and, even though I quibble about the grammar, I want it to be architected.

The article itself was written by a number of contributors and provide a mix of succinct insightful writing and some marketing waffle. One of the less well defined concepts was Enterprise Information Management (EIM) which is its 'technical trigger' phase rising to a 'peak of inflated expectations'. I find EIM a little similar to Knowledge Management (KM) which in turn can be almost anything related to the enterprise. KM can be include building design, HR practices and telephone lists. It was one of those definitions that a like to ask "What is it not?" and more to the point "How is it useful?". EIM, like KM will be more an approach to looking at the whole organisation. This may bring up some useful concepts. KM seemed to spawn the concepts of tacit knowledge and explicit knowledge. Before that people talked about the "stuff in our heads" and the "stuff written down" or for the geeks "biological data stores" and "digital data stores". Tacit knowledge was a vaguely useful concept. I don't think I'll championing my organisation to do EIM.

One of the more insightful parts of this article was the analysis of SOA by Roy Shulte and Yefim Natis. I am glad to see SOA is climbing the 'Slope of Enlightenment'. Something I have been struggling with is how many services my organisation has developed. I had assumed the number was zero until one of my senior developers showed me a list of all the EJBs he had built to access mainframe data and said "look at all these services". This did no fill me confidence. In a service I expect to see late binding, loose coupling, an XML interface, some aspect of self description and the ability to integrate using business process technology. Most of the SOA definitions I have seen are pretty vague and some a clearly business focused. These did no give me the ammunition to say that this was not the type of service I had in mind. The definition added to what I had seen previously.

"An application is an SOA application if it s modular; the modules are distributable; software developers have written or generated interface metadata that specifies and explicitly contract so that another developer can find and use the service; the interface is separate from the implementation (code and data) of the service provider; and the services are shareable..."

This should give me something to work on when I say I want this sort of service. Of course I could just say I want a web services with a SOAP interface. That might be easier. I get told SOA is not just web services though.

Hype cycles have their detractors but in general these hype cycles help see the big picture. IT shops are bombarded with a huge number of technologies. We are made to feel inferior by the marketers and our more progressive staff that we are behind because we are not employing the latest tools and techniques. The bottom line though is that many of these tools and techniques are not mature. They do not actually benefit all organisations and it takes time for conservative organisations to reap any benefit from investment some products that are billed as the next big thing.