another dated summary of a SOA conference

On Thursday, March 2, 2006, I attended the IBM SOA Architecture Summit at the Renaissance Hotel in Washington DC. The following paragraphs summarize some of the ideas that were presented as well as some of my thoughts. I have made no effort to consolidate these thoughts as time has not permitted. I do not explain acronyms as I expect people who might read this to already know the acronyms. This paper (a) serves to help me remember what I thought of yesterday and what was presented, and (b) serves to inform others at a high level what was covered in the summit.

Overall, the summit was good. I felt like it was a little long given that much of the day we didn’t get into what I would call the nuts and bolts of IBM’s offerings although the presenters indicated that they had. The speaker I enjoyed the most was a man who used to be a professor in computer science. I liked him the most because my academic background is in software engineering and that was the perspective from which he spoke. I got the most out of the early sessions as I was not quite as alert right after lunch. The summit closed with a Q&A session where I was able to get in the first question. My question was where IBM was in regards to the WS-BPEL Extension for People specification. I indicated that it was my perception that at the current time this specification mostly consisted of a white paper concept and I wondered when the specification might be finalized. They said that the standards committee on which IBM sits should complete the specification in 4-6 months and that it would be another 4-6 months before it was productized. Other questions that came up from attendees included:

How might contractors be given incentive to adopt SOA?
How could Government executives be sold on SOA?
How would one go about selecting a pilot SOA project?

As explained above, the following are random thoughts, observations, and points that I either had or that were made during the summit. Hopefully, if you are reading this, you will gain some kind of insight.

70-80% of most organization’s IT budgets is spent on maintenance.

In The World is Flat, a book that seems to be a favorite among Government workers, Thomas Friedman says”

"We are taking apart each task and sending it around to whomever can do it best, and because we are doing it in a virtual environment, people need not be physically adjacent to each other, and then we are reassembling all the pieces back together at headquarters or some other remote site. This is not a trivial revolution. This is a major one. These workflow software platforms enable you to create virtual global offices - not limited by either the boundaries of your office or your country - and to access talent sitting in different parts of the world and have them complete tasks that you need completed in real time."

In a report dated March 5, 2005, Gartner reflected, “Point to point interfaces result in an ever increasing burden.” (Duh!)

IBM’s SOA lifecycle can be summarized: Model, Assemble, Deploy, Manage, and Govern

A difference between BPM and BPR is the formers ability to model and analyze metrics before investing in actual development. In other words, the reason BPR was deemed such a failure is that months (and years) were spent engineering systems to replace older ones and by the time these systems were deployed, it was determined that the new processes were less than adequate. There was no support for capabilities such as process simulation as there is with today’s BPM products. Today’s BPM products allow rapid change and are agile and flexible.

SOA is much more than software. It includes governance, best practices, and education – among others.

IBM stated that we are past the disillusionment cycle on Gartner’s Hype chart.

Incidentally, one of the presenters stated that all of IBM’s software development was performed by AMS.

Distinct components that comprise architectures include: Systems, Data, Applications, Processes, Networks, Storage, and Standards. Each of these components should be loosely coupled.

In implementing pilot SOA projects, look for manageable project entry points. Avoid the “big bang” approach. Then: figure out the target reference architecture, develop a roadmap, and apply governance.

SOA has at least four important perspectives:

Business – SOA can be seen as Capabilities packaged as a set of services.
Architecture – SOA can be seen as an engineering Style, consisting of a Service Provider, Service Requestor, and Service Description.
Implementation – SOA can be seen as a Programming Model with standards, tools, methods, and technologies.
Operations – SOA can be seen as a Set of Agreements among Service Providers specifying Quality of Service, and key business and IT metrics.

Three principal SOA goals and benefits: (1) Separate specification from implementation, (2) Use higher abstraction from child to parent (as opposed to OOA/OOD which introduced the concept of inheritance from parent to child – which introduced other problems), Follow loose coupling. These three qualities allow for reusability, flexibility, and agility.

Five ways that SOA has transformed IT: (a) more standards-based, (b) greater degree of interconnectedness (while simultaneously providing for decoupling – in other words, greater interoperability) between components, (c) greater reusability, (d) greater focus on business rather than IT, (e) greater organizational commitment.

One of the differences between services and processes is that services are atomic and composite.

IT architecture can be thought of as consisting of five layers:
Consumers
Processes
Services
Service Components
Operational Systems

In this five layer view, Consumers and Processes are Implementation-related (and Consumer-based) while Service Components and Operational Systems are Specification-related (and Provider-based). Thus, the Services Layer separates the Specification Layers from the Implementation Layers.

A major element that was missing from the basic OOA/OOD/OOP world was that of having objects “talk” to one another. This created too many interfaces as we can see from the many spaghetti-drawn software architecture diagrams. The introduction of the ESB serves this purpose.

Three elements of Business-Driven Development: SOA (provides flexibility and reuse), Model Driven Architecture (provides efficiency and quality), Business Innovation and Optimization (provides for responsiveness and (I will add) Competitive Advantage)

For examples of patterns, go to http://www-128.ibm.com/developerworks/rational/products/patternsolutions

Another layered approach can be seen below (remember the old OSI seven layer view?):
Layer One Network layer (i.e. http, smtp)
Layer Two XML (i.e. Infoset, namespace, schema)
Layer Three Service Description (i.e. WSDL, RAS)
Layer Four Invocation and Messaging (i.e. WSI, SOAP)
Layer Five Service Discovery (i.e. WSIL, UDDI, RAS)
Layer Six Service Orchestration (i.e. BPEL)

Today there are two kinds of developers: application and integration. Integration Development consists of both and primarily Information/Data Integration and Message Integration.

Orchestration and Choreography separates business logic (business rules) from control logic.

IBM’s tools allow you to move from Requirements Management (Requisite Pro) to a process model and, in turn, process models can be turned into UML. A tool included in this process includes Software Architect in addition to Rational Rose. From their development platform, one can alternate between different views: Software Architect, Application Developer, Integration Developer, Business Modeler all in a single UI which is based on Eclipse, an open source development UI.

Service elements to consider when thinking about the concept of coupling include: services, messages, interfaces, contracts, policies, conservations, states, transactions, and processes.

Why is SOA a big deal? Because it provides for a self-describing component that provides services based on standards. We have had these before but not all at the same time.

Business Processes can be managed through BAM, Dashboards, KPIs (Key Performance Indicators), etc.

Eleven elements of Governance: Incentives, Mission, Domains, Enterprise Architecture, Technical Standards, Development and Deployment, Operations, Roles, Organizations, Processes, and Shared Services.

Shared Services leads to the establishment of authority:
Authoritative Services
Authoritative Data Sources
Authoritative Semantic Meaning of Data and Services

In establishing a process framework, think of:
What has to be done?
What is scope of policies?
How will it be accomplished?
Who has authority?
When is oversight and control provided?
Where is governance enforced?
How is capability measured?

IT & SOA governance needs to come together. The most important best practice is for the CIO to report to executive leadership.

In laying out an SOA roadmap (this is an iterative process):

First, what is the scope and what are the pain points?
Second, assess current capability
Identify gaps between desired capability and current capability
Create a roadmap
Execute


Four possible entry points for an SOA: create services from new or existing application (this is NOT an SOA – just code), implement a SOA pilot (preferred initial entry point), LOB process integration, and enterprise business and IT transformation (if you start here you will probably fail). Suggestion: start at possibility two and proceed through to possibility four.

Degrees of integration include (in order – BTW I missed one but I thought this was an interesting continuation): silo, integrated, componentized, virtualized, dynamically reconfigured

IBM used GCSS-AF as an example of a successful SOA project!

IBM recommended that all organizations establish an SOA Center of Excellence.

The TAFIM has evolved into the TOGAF. I am familiar with FEAF, DODAF, etc. but not TOGAF.

IBM states that functionality should be subordinate to architecture. One of the audience members asked during the Q&A function how this can be mandated since people’s careers are based on functionality?