I Hid the Turd

Dear Mr. CIO,
I regret to inform you that I've been hiding a massive turd from you and the business units for several years now. The turd is the "3-tiered silo application". The stench was horrid - I was forced to get some industrial grade air fresheners that I called "EAI and ETL". I feel very bad about this, as does my staff. Although, there were several times where you called us into meetings and we all had those 'shit-ass grins' on our face and you thought we were making fun of you - good news - we weren't, we were laughing about our hidden turd.

But I don't take all the blame. You remember when you asked us to do 12 major initiatives and we told you that we didn't have the staff? Yea - well, we didn't. So we cranked out as much as we could and patched the crap together with messaging. From an architectural perspective, it's a freaking mess!! We've got data replication, batch transfers, multiple message formats, multiple transports, platforms, vendors - wow, I can't believe you didn't fire us!!

The reason that we are 'coming clean' is because we believe we've found an answer. It turns out that using simple protocols and a network programming model that isn't vendor specific will allow us to build connected systems. Also - we discovered this other wacky thing - this new model called SOA actually aligns to the needs of the business.

Now that we're being honest with each other, I feel it necessary to inform you that this SOA thing... is right, but - it actually takes a bunch of planning and architecture. It's like - ya-gotta-use-your-brain-kinda-stuff. And not to drop another bomb on you - but a bunch of these guys around here are morons. Now, I know that you have deep pockets and short arms and don't like to pay for real talent, but I think your screwed if you don't. So, it's your call.

In the meantime, the Turd guys, came up with this new turd-containment concept that they call an ESB. I don't know what it stands for but I talked to some smart guys and they said that it was supposed to be SOA but the vendors missed their deadlines - so they just repackaged their old turds with some new SOA stuff. So, just beware - were probably going forward with the turd-containment stuff and later we'll have to go with real SOA stuff. Sorry for hitting you with all of this.

Sincerely,
Your Entire Staff

Requirements & Specifications in Service Oriented Systems

I couldn't help but notice that the cover story for CIO magazine was about the requirements process and the awful state that it is in. I tend to agree. When I visit customers I see one of two things:
1. The company has perfected requirements for silo based systems
2. The company stinks at requirements all together

I've looked at many systems that people wanted to upgrade, rewrite or replace using service oriented techniques. As a habit, I ask for the original requirements document for the production system. I then play this game to see if I can trace 'silo' or 'closed' characteristics back to the orignial requirements and specifications. In general, these characteristics are usually described in the 'supplementary specification' or in a supplemental 'non-functional requirements' document. And in virtually every case I am able to trace the issues back to the original documents.

One of the significant changes in the 'service oriented enterprise' is an renewed emphasis on: portfolios, product lines, business processes, enterprise requirements and cross-cutting concerns. We are stressing to our customers that they MUST revisit the requirements process and move to an 'enterprise grade' method. That said, I am proud to announce a new course from MomentumSI, "Requirements & Specifications in Service Oriented Systems"

The course is directed at the Business Analyst, but would valuable for anyone that participates in the requirements & specification activities.

---

Course Outline

• Overview of SOA for the Business Analyst
  
• The Business Impact of SOA
  
• The Awesome™ Method for Business Analysis
  
• Strategy, Portfolio Analysis and Business Case Development
  
• Generating Stakeholder Requirements
  
• Coordinating Enterprise Requirements
  
• Validating Stakeholder Requirements
  
• Generating Engineering & Procurement Specifications
  
• Managing Change throughout the SDLC
  
• Examples and Cases

---

I firmly believe that those companies that continue to use 'silo based' requirements processes will fail in adopting SOA. We will begin offering this course in January. If you're interested in the full course description, just send Alex an email: arosen [at] momentumsi.com

The SOA Ecosystem

MomentumSI is a consulting company that specializes in SOA. We help companies with their SOA strategy, plans, vendor selections, architecture, infrastructure, education and business projects. In this role we have a birds-eye view of the SOA landscape, and one thing is clear:

"An SOA Ecosystem is quickly evolving and those inhabitants that fail to recognize the rules of the system will likely wither and die. "

In the year 2005, one significant event took place in the SOA ecosystem. Vendors that were amorphous found shape and structure. Full fledged product categories emerged: SOA Registry & Repository, SOA Management, SOA Intermediaries, SOA Governance, SOA Security, SOA Data Services, SOA Process & Workflow, SOA Testing and SOA Legacy Integration.

As the organisms explored the ecosystem, they found each other. They stared, sniffed and prodded. They identified competition, but most importantly many of them found cooperation. After first contact, emphasis was placed on removing their overlap and short-comings and they began the process of morphing themselves to become "SOA Eco-Friendly".

The SOA Ecosystem will be governed by the laws of all ecosystems. And I strongly encourage those inhabitants to know the laws:

• Symbiosis is an interaction between two organisms living together in more or less intimate association or even the merging of two dissimilar organisms.
• Parasitism, in which the association is disadvantageous or destructive to one of the organisms and beneficial to the other.
• Mutualism, in which the association is advantageous to both
• Commensalism, in which one member of the association benefits while the other is not affected.
• Amensalism, in which the association is disadvantageous to one member while the other is not affected.
• Predation is an interaction between organisms in which one organism, the predator, attacks and feeds upon another, the prey. (wikopedia)

I've been flying around the country talking with large and small SOA product companies about the ecosystem. As a preferred 'SOA integrator' we see the problem from the view of the customer. And as the champion of the customer, we are unable recommend products that exhibit characteristics which negatively affect the customer. Examples include:

1. Portfolio Coupling - Single vendor solutions mandating a daisy chain of products all from the same vendor. Example: If the vendors Process Server requires the vendors ESB which requires the vendors Application Server and the vendors Database Server.
2. Product Coupling - A single product that contains multiple capabilities, where each capability is really a standalone product. (First generation BPM products fell victim to this).
3. Closed System - A product that fails to have integration points into the other inhabitants of the SOA ecosystem. We don't have the equivalent of a J2EE specification for the service oriented / Web service world. The burden to identify and specify integration points and mechanisms is placed on the vendors by the customers and consultancies.
4. Inch Deep, Mile Wide - In the early days of SOA, many vendors were chasing the 'SOA platform'; they provided a little bit of registry, a little bit of orchestration, a little bit of mediation, etc. but failed to excel in any one area. The Darwinian nature of the SOA ecosystem will kill off those vendors that fail to specialize (a mile deep). IMPORTANT: This will force some vendors to abandon entire products or modules and to replace this functionality with 'open system' integration points to best-of-breed providers.

The SOA ecosystem must place the customer at the center. Modern SOA infrastructure must be capability oriented and loosely coupled via standardized policies, metadata, protocols, formats and identifiers. Vendors must recognize the architectural ecosystem, the elements, their relations and constraints. As corporations spend millions of dollars to decouple applications, they MUST place an equivalent emphasis on procuring from those vendors have eco-friendly offerings.

Judith Hurwitz on SOA

With the boot camp consuming my time, I've had to queue up lots of blog posts on recent topics (SOA Maturity Models, Frankenstein, SOA Analysts, Big 5 SOA methodology / scribblings, etc.) But I thought I'd lead with a piece found at the CIO magazine - only because the Judith/CIO magazine combination influences a crowd that needs correct information.

Judith Hurwitz presents her 'ten principles of SOA' in a piece on SOA: Battle of the Titans. My comments follow.


SOA is real. It is not a quick fix. It is a ten year journey (or longer) that requires considerable planning. It is also as profound and far reaching as, for example, e-commerce.

Agreed.

SOA is build upon 15 years of experiments in creating highly distributed computing environments that take into account everything from load balancing, software distribution, security, and data management including meta data management and registry. SOA embraces all these aspects of computing and takes them into account.

Agreed.

SOA will only work if organizations lead with manageability. SOA by its very nature demands the aggregation of IP from many different sources. Scalability within SOA will come from managementÂ?not development.

It was funny listening to all of the vendors at the boot camp. Each one told us what to lead with - 'Lead with the Registry!', 'Lead with Mediation!', 'Lead with security!'. Now Judith might be talking about SOA Manageability or about general governance - it's impossible for me to comment on what she meant. Regardless, I'm comfortable stating that you should lead with SOA strategy and incorporate a closed loop infrastructure. All of the components must complement each other - no one component is at the heart.

SOA will only work if it is implemented within a business process context.
SOA is predicated on leveraging business services that constitute the component parts of your business.

Yea - this is wrong. It is common for a newbie to watch a demo of BPEL/XLang/BPML orchestration and think that they just saw the future of computing. Better yet, they grasp the concept of a 'business service' but fail to realize that this is the ONE thing in SOA that will see the LEAST amount of reuse. Don't get me wrong - there will be some instances whereby SOA enables process-driven applications, but this is merely one of a dozen or so benefits.

SOA requires a container that creates a composite application.

I'll remind Judith that she characterized SOA as working in "highly distributed computing environments". Service based applications come to life by activating services in well known sequence. The composition (or invocation) of these services are distributed. The app server/container metaphor takes on a new meaning. Service oriented applications have 'invocation points' or 'composition points' at multiple layers in the architecture (virtual business service, business service, virtual data service, data service, etc.) The key here is to not accidentally use the term 'container' in the singular. How about, "Composition of service based applications is usually distributed, with no central composition point or single container."

SOA requires standards that can be depended upon across all vendors implementations of SOA.

The ONE truth about SOA is that we CAN NOT DEPEND on standards across all vendors implementations. If you don't understand this, you don't understand SOA. The reason that SOA will work is because we have factored out the non-functional concerns and created transformable protocols, formats and identifiers of the standards which are MEDIATED.

SOA assumes that you will begin to write applications differently as a series of tightly defined services implemented in a loosely coupled manner.

I guess... :-)

SOA assumes that each component part is equipped with a clearly implemented web services interface based on standards.

Agreed. They just don't have to be the 'Web Service' standards, nor do they need to be ubiquitous. They just need to be federated, virtualized and mediated.

SOA dictates that change is the norm since this approach to software mimics the way a business operates and evolves.

SOA is a pain in the ass that, in the short term, will slow down your ability to rapidly deliver software to your customers. SOA doesn't provide rapid change but it does provide a framework for 'scaling capability'. As the number of enterprise concerns rise (consistent data, consistent logic, fulfilling regulatory mandates, process as a first order concern, one-face-to-the-customer, etc.) we need a framework to allow us to change EXTREMELY complex systems. SOA enables the insertion of capabilities in an incremental (and almost linear) manner.

SOA is complex. Explaining it to CIO's is even harder. I wouldn't expect Judith to go to the detail that I just did for the audience she was catering to. However, the amount of poor advice provided is, in my humble opinion, disappointing.