The Service Network - July 2005

Our July edition of The Service Network is available.

And yes, the favorite line seems to be:

"SOMA (Service Oriented Modeling and Architecture) –Vaporware or IBM Global Services with a copy of Visio?"

When will SOA take off?

In 135 days.

Seriously - the Web service and SOA era will begin in 135 days.

176 I.T. Jobs Posted in USA

In the last 24 hours, 176 I.T. and software related jobs were posted on Monster.com...

I was curious how many were posted in India however it was difficult to tell. Even when limiting the search engine to only return jobs posted in the last 24 hours, the number posted exceeded the limit. I attempted to further tune the search criteria but was still hitting limits.

My best guess is that in the last 24 hours approximately 3,000 to 4,000 jobs were posted on Monster.com for India.

After sampling the job descriptions, it appears as though approximately 70% of the jobs posted in India were designated to fill U.S. demand. If this math is correct, that means that for every software job requirement that is posted in the United States, fourteen are posted in India to fill the same U.S. demand.

AToM: Sun Needs to Learn From Microsoft

We have a clear winner in the quote of the month category:

Anne Thomas Manes, a Boston-based analyst with Burton Group Inc., echoed those sentiments.

"What bothers me is that I really don't like JAX-WS," Manes said. "The Sun JAX-WS team really needs to learn a few things from Microsoft. They should be building something like Indigo—a common programming model that encompasses JAX-WS/JAXM, JMS, RMI and EJB. But Sun doesn't get that."

Can someone please send me the name of the person at Sun who is responsible for this? (Yes, I'm still interested in seeing prediction #7 of 2004 come true... how sad.)

The WSDL is the Offshore Contract

As more and more organizations move large portions of their I.T. department to offshore facilities they are questioning which activities to keep on-shore and which to push offshore.

For those that have chosen a service oriented path, the decision seems to be clear: "The WSDL is the Offshore Contract". In other words, domestic employees will work on business processes, enterprise architecture, orchestrations (agile controllers) and service design (up to the WSDL). And building the service? You got it - offshore.

It's an interesting line to draw, yet perhaps an obvious one. Using the "software contract" as the "legal contract" invites a clean division of labor and facilitates a simple approach for acceptance testing.

Obviously - the WSDL only defines the external interface leaving other aspects of the service (LIKE THE INTERNALS) to be described by other mechanisms. The algorithms and business logic are described with variations of the Use Case (think 'service case'). The relationship between the server and other elements (the hosting container, other services it calls, etc.) will likely be described by the System Definition Model, or some variation.

The science of describing architectures, interfaces and dependencies has significantly increased in recent years and it appears as though we are entering an era where the adoption level will skyrocket. The ability to describe systems in this fashion is what I've been calling 'precision specifications'. By using digital definition languages like SDM and WSDL, we are able to provide a 'software factory' with clear directions for construction.

Using 'services' as the unit of work appears to be a very manageable approach. Companies that are big into test-driven development will likely find test-driven-services a natural extension. Organizations that have adopted the Agile Manifesto may find this world too rigid. However, the Extreme Programmers may like the ability to lump X number of services into an iteration plan. And project managers will be thrilled to see acceptance tests directly linked back to line items on the Gantt chart.

I.T. organizations must increase their capability to describe systems with precision specifications prior to initiating a 'SOA factory'.

CIO's Aren't Taking SOA Serious

I'm going to make a quick prediction:

More CIO's will lose their job over SOA implementations than lost their job over ERP implementations.

---

I was chatting with a CIO the other day and asked him, "In retrospect, do you think you were involved enough in the early stages of your ERP implementation?"

He answered, "In retrospect - no - I wasn't involved enough. Had I known the size of it I would have definitely gotten more involved."

I followed up with, "Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?"

He started laughing; he thought I was joking. My face didn't change. He quit laughing. "Jeff, are you serious?"

"Yes, I'm very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP."

He responded, "But with ERP, it was an all-or-nothing approach. Doesn't SOA offer an incremental approach - one that can be managed better?"

"Yes and No", I responded - "SOA is first and foremost about a network of services. The value of your service network is directly related to the effort of creating/obtaining services and making them available. All networks require a critical mass of 'valuable services' before they become useful to the consumers. The SOA service network is no exception. What I'm saying is that you can take a slow and steady approach to SOA but be prepared to receive gains that are even slower. Remember - this is really about the 'network effect'.

SOA done properly is a massive undertaking. It requires a rethinking of your infrastructure, development methodology, business impact analysis, budgeting process, organizational design... Don't underestimate the value it provides, the competitive advantage one can assume AND the investment it will take!"

It was clear that I had surprised my friend - perhaps even scared him a bit. And I realized that so many of the people in this space (vendors, analysts, press) are doing a disservice to the CIO by failing to tell the whole story: An Enterprise SOA implementation will be larger than ERP, Y2K and the Web.

Now is the time to get involved.

SOA Training!

For the last couple years we've been training people in SOA and Web service technologies. Recently, we've added a couple courses including "SOA for Architects" and "SOA for Managers" - both excellent.

See:
http://www.momentumsi.com/services/training.html

I'd love to do a course on buidling your SOA Reference Model...

Hiring SOA Consultants...

Momentum is opening up new positions for SOA consultants. All positions are travel intensive and require a strong background in distributed computing and enterprise architecture. Interested candidates should send Melissa a note: careers@momentumsi.com

We're basing the consultants in one of three delivery centers:
- Austin / Dallas, Texas
- Reston / Washington D.C.
- San Francisco / Silicon Valley
------------------------------------------------------

The Service Architect
At Momentum, the Service Architect is responsible for analyzing architectural requirements and translating into service based solutions. The architect will work with various existing architectural styles (monolithic, client/server, 3-tiered) and modify those systems to accommodate a service based approach. The architect will also be responsible for identifying SOA based solutions to the non-functional requirements (security, transactional integrity, reliability, availability, agility, etc.) Lastly, the Service architect will be instrumental in creating Software Architecture Documents, identifying components, estimating time-to-transition, providing guidance to designers and developers and linking architectural investments back to financial returns.


Requirements:

The SOA Architect must be well versed in Enterprise Architecture, Service Oriented Architecture (SOA), J2EE and or .NET Architecture.
Full life-cycle implementation experience (requirements, design, implementation, integration, testing).
Experience designing and implementing n-tiered application architectures.
Fluency in first generation web services standards, technologies and tools (e.g., XML, SOAP, WSDL, UDDI, BPEL, etc.).
A strong distributed computing background is a requirement (CORBA, RPC, DCE, DCOM, RMI).
Familiarity with messaging systems is a plus (Tibco, WebMethods, MQ, SeeBeyond).
Familiarity with commercial Web service products is a plus (Systinet, Blue Titan, etc.).
Knowledgeable on WS-* standards.

Other:

• Strong interpersonal, strategic oriented thinking and excellent written and verbal skills are essential.
  
• Ability to present professionally and persuasively to C-level executives.
  
• A minimum of 10 years experience overall in software development.
  
• A degree in Computer Science is preferred.
  
• Travel is required for this position.
  

About MomentumSI
MomentumSI is a pioneer in service oriented architecture, integration, and application development. Since 1997, the company has built a reputation as a leader in architecting large scale distributed computing solutions for IT organizations. Today, MomentumSI is at the forefront of service oriented architecture and integration for enterprises. We built the first Web service orchestration server for .NET and have been an active member of Web services standards groups, such as OASIS. Momentum continues to invest our SOA practice and is looking for the best of the best to join us.

Entire Software Sector up on Web Services!

Now this is interesting:

NEW YORK (MarketWatch) -- Goldman Sachs raised its rating on the software sector to attractive from neutral on the belief that the emergence of Web services architecture will accelerate industry growth and on expectations that share prices will rise as investors position for an anticipated year-end rally. Analyst Rick Sherlund believes a movement to a new generation of Web services base standards, which will result in more flexible and adaptable systems that can allow for changes in business processes, could reinvigorate growth for information technology vendors. He said the Phase I adoption of infrastructure software from IBM , BEA Systems , Oracle and Microsoft to enable the new standards is well underway, and the Phase II re-architecting of existing applications from SAP , Siebel and others is upcoming. He said Phase III will be integrating the new standard into desktop systems, which should stimulate a replacement cycle. Sherlund recommends positioning in the expected leaders of the next generation systems, even if the benefits aren't expected for a few years, given attractive valuation and the anticipation of a typical year-end rally.

See: http://biz.yahoo.com/cbsmb/050523/390440d059074e4881ce4b5a86c54332.html?.v=1

Increasing Reach

Software reuse has always had issues. In my opinion, the most common types of reuse are:
1. "Copy & Paste Reuse".
2. Off-The-Shelf Reuse - Here, we leverage JVM's, .Net API's, J2EE libraries, open source offerings, etc. that are pre-built and providing immediate value.

The third (and elusive) category would be the homegrown libraries - often domain specific. Let's be clear - the more general the problem, the easier to reuse; conversely, the more specific the problem, the harder to reuse. The easy stuff is packaged in your favorite off-the-shelf library - leaving the more difficult stuff for the I.T. department.

Reuse is difficult - and reuse via language specific code snippets is often easy but fails to scale and provide real value. Reuse via off-the-shelf packages is great - but in many organizations - this one has already been tapped. This brings us to Reuse Through Reference.

Services are a great mechanism for providing reuse through reference - however, many people seem to forget one simple item: REACH.

Reach describes the 'reusability potential'. Imagine having 10 systems 9 of which were in COBOL mainframe apps and the 10th was a .Net application. Let's state that the COBOL applications don't have the ability to access the native services provided by the .Net application, but do have the ability to talk Web services. Interesting - I just stated that it can speak "Web services" - does that mean WS-I basic profile? Which other WS specs does that include?

In an attempt to increase reuse through reference, we (the enterprise architects) are finding the need to increase reach. This means that we must identify protocol ubiquity levels within our organizations and quickly create critical mass.

Generally speaking there are two methods for increasing the reach:
1. Modify the connector capabilities at the endpoints (COBOL apps, etc.) via service enablement (WS-PaintJob)
2. Provide protocol mediation/translation in the network.

WS-PaintJobs are an easy way to black box systems and increase reach. However, the total number of protocol permutations between any given client and any given service grows exponentially with the size of the service network. This leads to the realization that a protocol mediation strategy is not only useful but mandatory.

The Client-to-Service Ratio

It is natural for people to think about their SOA in terms of the number of services that they have created. And as one person joked the other day, every company seem to report having between 200 and 500 services. The criteria for being a service tends to vary significantly - anything from XML over JMS to EJB's to WS-I compliant Web services.

Service Architects love to brag about the number of services - and I let them. Actually, I encourage them to brag. However, I'm quick to challenge these same people with a very simple question:

"200 SERVICES! That's great - but how many clients???"

This simple question usually makes the most pompous architect fall to their knees in shame.

You see, one of the reasons that guys like me go around shouting "SOA, SOA, SOA!" is because we believe that a sharable infrastructure can be used across "applications" to enable a new level of productivity. Yes, we believe in the unicorn called "reuse". The "how many client" question hits at the heart of the share/leverage/reuse debate. I know it - they know it.

Back to my story - I ask the question, "How many clients" - and I stare at their face like a CIA agent looking for twitches. Within seconds, I witness the five phases of panic :-)

Phase 1: "Oh crap. I should know this."
Phase 2: "I better make up a number - I told him 200 services - hence I'll tell him 200 clients!"
Phase 3: "Nope - that won't work - he'd realize that my client-to-service ratio would be 1:1 indicating that I wasn't getting any leverage."
Phase 4: "2:1 seems high at this stage; 1.5:1 seems believable... yea, (1.5 * 200)=300... but I can't tell him 300..."
Phase 5: The Service architect looks me squarely in the eye, head shifted slightly to the left and says "Currently, we have 322 clients."

And I say - "Excellent" followed by a slight grin and a playful stare indicating that I was 100% aware of what had just occurred. I usually then move to relieve the 5 seconds of torture and lies that I just put them through by saying something like, "Well - it is still early; SOA is still evolving and you won't see that number climb until more of the organization adopts it." And my friend gladly take the bait - "Absolutely! Right now, we're just building out the core services - we're confident that the ratio will increase over time."

And I move on to question number 2...

Nokia & Web Services

VNUNet.com reports:

"Nokia has vowed to build support for web services into all its smartphones by the end of the year.

The firm explained that the development push will include support for common software standards including Soap and XML, as well as for more intricate applications.

In the future both the Series 60 smartphone operating system and the Series 80 software used in the Communicator range will offer full web services support.

"By 2006 all Nokia smartphones will be web services enabled," said Timo Skytta, director of web services at Nokia.

Most excellent!

SOA - PHASE III

Several of my buds have been giving me a hard time. They're claiming that I've checked out of the SOA world. And as an emerging tech. guy, I'll agree.

You see, from my vantage point - SOA & Web Services have already crossed the 'value' threshold and are ready for adoption (Gartner is wrong.) Dare I say that WS is no longing 'emerging'. We have now entered phase III.

Phase I was basically 'protocol oriented' - with a focus on the WS-I Basic Profile (SOAP, WSDL, UDDI, XML Schema). Phase II was the WS-* stack (the aspect oriented protocols).

Phase III is about the using the darn things. Whacky, eh? You see, I talk with hundreds of companies about their utilization of web services. In most cases they tell me this:
1. We connect fat .Net clients to Java application servers (and use soap in between)
2. We connect to some ASP (like Amazon, SF.com, etc.)
3. We front ended some legacy system with services.
The same companies will brag about their rich utilization of UDDI, Fabric, ESB, etc.

However, when I ask about SOA from a reference architecture perspective, I mostly get blank stares. Then, I go to the white board, hand them the marker and say, "draw your architecture and show me where you use services." And in almost every occassion they draw an application architecture which is usually a 3+N (the usual 3 tiers plus roughly N external services - pick your favorite - LDAP, EII, orchestration, etc.)

So after seeing the same thing at several different companies you begin to realize that the world is landing on patterns of usage (and yes, 3+N is the most common). But rather than calling these 'service patterns' or something like that, they are really just architectural patterns (that use services).

Full Circle.
It's true - I'm less interested in watching protocol geeks fight in OASIS about non-sensical issues. We're finally here. We're finally at a point where we can use this stuff to create business value. That said - phase III is all about facilitating the adoption. And yes - expect to see pre-canned architectures that use SOA. But beware - the shift is heading back to 'architecture as a whole' and reviewing the place for SOA / WS in our upgraded world. You see SOA Phase III is really about putting cleaning up our distributed architectures and applying SOA appropriately.

Architecture Change Request (ACR)

There are a number of studies that discuss the impact of failing to adequately express system specifications. Oddly, most of the studies focus on the 'functional' side of the equation emphasizing the Use Cases or similar requirements document. As more and more of our work efforts are being moved to assembly line creation (outsourcing, off-shoring, remote development), it is becoming much more important to clearly articulate system specifications and the change requests.

I've witnessed teams go through great pains to version control the least important documents in the system. Source code, JavaDocs or test cases will be meticulously controlled, while the over-arching architectural documents will often go unattended. When they are versioned, they are usually treated as a BLOB, with no ability to perform a "Diff" or to maintain an automated digital log of the changes.

As organizations begin to adopt digital described reference architectures and use those elements to digitally describe their candidate architectures, they will find the ability to perform the 'diffs' and to manage change at an acceptable level.

Suddenly, we begin to see our architectural process looking much more like traditional hard-goods engineering process:


The Architectural Change Request (ACR) enables a software development team to track the changes to one of the most important elements in the SDLC, the architecture. Keep in mind, when architectural changes are made the impact (time / money), is usually significant. I firmly believe that the ACR/ACO process will encourage application architects to think and plan their architecture out more thoroughly at the initial stages leading to less rework after the project is initiated.

ADL, IDL & EDL

There are several different ways to review elements in an architecture.

1. You can look at the "interfaces" to identify the entry and exit points. Obviously, this is a big part of what web services are all about with WSDL as an "Interface Definition Language" or IDL.

2. You can look at the "engine" that provides the base infrastructure: "It's a database! It's a Rules Engine!", etc. Or more precisely, "It's an Oracle Version X database, with clustering". This is the "Architecture Definition Language" or ADL.

3. In addition, you can look at the mechanism that is used to "extend" the "engine" which provides the "interfaces". In an orchestration engine, the extension language might be "BPEL", in a presentation engine, the extension language might be "JSP". Once an EDL is identified, you can begin to look at the capabilities of the extension mechanisms (language features, libraries, etc.). Unfortunately the industry remains very immature in this area. However, I am confident that as the industry begins to understand the basics of a "language to create/describe languages" the art will quickly advance.

The software community is making progress in describing the systems we build. Our meta-descriptions of our building blocks and finished systems is a huge advancement toward the vision of the "software factory", "software IC", or which ever metaphor you prefer.


-------------------------------------------
INSIDE, OUTSIDE, UNDERNEATH & ALL TOGETHER!

Web services & SOA make people think about architecture from the "OUTSIDE" - that is, the external interfaces. The "EDL" allows you to evaluate it from the "INSIDE" - or how you build that which is exposed. The ADL facilitates "UNDERNEATH & ALL TOGETHER".

Although one of the primary benefits of SOA is to abstract the consumer from the architectural elements and extension mechanisms, this doesn’t mean that the architect that is creating the solution can avoid the issue. I firmly believe that the opposite is true. SOA architects must apply equal attention to these concerns as they do to their uniform interfaces, mediation strategies or WS-catalog taxonomy.

----
Note: I'm using the term EDL to describe the capabilities of a DSL or a general purpose programming language.

SDM - it's right.

My father bought one of the first 100 TRS-80 computers ever made and at the age of 11 I was fluent in assembler. By the time I finished high school, I could program in 14 languages. I've found other people who have similar backgrounds - and in almost every case they share a similar trait: the ability to recognize a disruptive technology.

In my career, I've made a few "early calls":
1985 - Windows 1.0
1991 - Visual Basic 1.0
1993 - PowerBuilder 2.0
1995 - Java
1997 - XML
2002 - BPEL

and now,
2005 - SDM

It's that big. It's right - and it will change our profession.

Canned Architecture

Several things in the Agile world has always bothered me. The one I'd like to point out today is the concept known as BDUF. The summary of BDUF is:

"The term BigDesignUpFront is commonly used to describe methods of software development where a "big" design is created before coding and testing takes place. Several ExtremeProgramming (XP) advocates have said that such "big" designs are not necessary, and that most design should occur throughout the development process."

Over the years I've noticed that the closer one is to the code, the less they tend to distinguish between architecture and design. "Code Intensive" people tend to be bottom up guys - they start with code, refactor to a new design - rewrite, refactor, repeat. Call me old fashioned, but I firmly believe in the use of enterprise reference models, template architectures, application blocks, architecture & design patterns and candidate architectures. This clearly puts me in the bucket of "Big Architecture Up Front" - and I'm proud of it.

In the last 8 years at MomentumSI, I've had the chance to see hundreds of projects across our clients. And the one thing that has always amazed me is the reusability of architecture and design elements. Sure, the platforms change - new elements are added - the functional domain is different, but for the most part the basic architecture and design is usually about 80% reusable.

To clarify my position, I'm really a "Canned Architecture Up Front" kind-of-guy. In working with architects, I've noticed an interesting behavioral pattern. Application architects realize that when their architecture is "finished" they're probably going to have to do "design work" or God help them, "coding". For this reason, they tend to re-invent architectures and make them drag on for long periods of time. This is bad.

We are in interesting times. I'm predicting that the "Big Custom Architecture Each Time" guys are going to find themselves in a pinch. Microsoft (and others) are moving us into a world of "drag & drop architecture".

Microsoft's decision to embrace an Architecture Description Language (SDM - the Systems Definition Model) has the potential to overhaul the profession. SDM will likely spark a renewed interest in creating digital descriptions of our architecture, leading to an ADL competition and overall advancement of the discipline.

Digitized architecture also has a greater potential for enabling architectural refactoring, automated vendor sourcing, self-reflecting documentation and automated environment provisioning. But the thing that gets me excited is significant reduction of 'architecture time' by using enterprise-grade, off-the-shelf, canned, distributed architectures.

SOA: Business Impact Strategy

A major shift has been occurring over the last few months in the SOA adoption curve. "Business people" are now being tasked to understand the strategic business impact of SOA/Web Services in their organization. This is a significant deviation from the last set of strategy calls around "strategic SOA implementation".

Many organizations have completed the first stage of maturity. That is, they have a SOA strategy in place, a SOA methodology, a reference model, candidate architectures and core infrastructure components (registry, repository, SOAP routers & firewalls, pipe & filter mediation, service bus, SOA EII, metadata compliance, testing suites, SOAP-to-Legacy adaptors, specialized "service servers", etc.) Typically, a core team has been trained but a larger training plan is available. Again - this is in "leading organizations" - not the majority!

These leading I.T. organizations are now giving the business units the go-forward nod, indicating that they have their act together and passing the baton to the business units to make the next move. Much like we saw in late 90's around the Web, business managers are looking at the capabilities of the technology, studying the disruptions and applying it to their domain.

I'm starting to see SOA patterns of disruption emerge - but it is still early. Very exciting - more to come...

SOAP isn't Dead

The recent garbage being posted about "SOAP being dead" is just that; it is garbage. It is agenda pushing in the hope of creating a self-fulfilling prophecy. And I'm calling bullshit.

Stating that we should use a distributed computing model that fails to handshake the non-functional concerns is sophomoric. Enterprises require a new level of ubiquity for specifying the quality attributes in distributed systems - it's that simple.

I don't care what Google, Ebay or Yahoo are doing for non-critical SOA enablement. They do what they have to do to get Joe-schmoe on board. Following the e-leaders in a time where WS-* remains in a pre-ubiquitous state is just plain silly.

SOAP isn't dead. Let's all beware of the "Blog Oriented Architectures".

Layers in a Service Network

The concept of a layered architecture has deep roots in computer science. It has been applied to protocols, networks, operating systems, containers and applications. In 1996, POSA Volume I clarified the meaning of the layered architecture. The pattern states that the lower layers are 'unaware' of the higher layers. In this manner, layers are used as an abstraction mechanism to facilitate decoupling.

Although there are variations of this pattern, the most 'pure' version is where a layer is ONLY called by the layer above it. Lower layers will attempt to respond to calls from the next higher layer. However if the layer requires assistance, it can only make calles to the layer directly below it.

IBM has recently made a stab at a "partial layered architecture":



In reviewing this diagram, the obvious question is, "what the heck are those two vertical layers?" The equally obvious answer is - "those are the areas where the (horizontal) layered architecture are violated!" I feel quite comfortable saying that IBM's layers 6 and 7 gotta go (as layers). On occasion, an architecture can be modified whereby it is classified as a hybrid, but even then, the author must be VERY CAREFUL to make sure that they didn't just kill the intent of the original architecture.

Let's get to the root of any layered architecture. They all look like this:
- The very top layer is the 'Ask Only'.
- The very bottom layer 'Respond Only'.
- All layers in between are both (they ask and respond).

That said, it is pretty safe to put the human interface as the very top layer :-) To my dismay, humans still don't implement WSDL's. Until then, I'm comfortable keeping IBM layer 5 (the ultimate client).

The bottom layer is quite tricky. One might think that it would be safe to drop things like ERP, CRM and legacy apps there. However, the truth is that those applications will be the MOST LIKELY to be clients of business and technical services! Hence, I am equally comfortable killing Layer 1.

Layer 2, had me stumped. It is hard to dispute that services could sit on top of components. But on that note you could argue that components sit on top of objects, and objects sit on top of virtual machines, etc. At the end of the day, I believe that components shouldn't be depicted in the enterprise view of a layered service network. A more appropriate view of this relationship should be in the 'service view'. If a service is designed with a layered approach, it may be appropriate to show the component-to-service layering. Hence, I am equally comfortable killing layer 2 (from the enterprise view).

Layers 3 & 4 are tricky. Here is the big question: "Is there ever a time when a composite service needs to call a process orchestration?" (Will layer 3 need to know about layer 4?). I'd like to say that there will be a clean separation between process logic and business logic, but I'm just not sure. It seems as though IBM is having a tough time separating functional concerns from mechanism. The aggregation of one or more services using a loosely coupled technique (like BPEL, itinerary based routing, content based routing, etc.) will find it's way into both composite services as well as into process orchestration. And tagging flow of control logic as either 'process', 'workflow' or 'business' is extremely hard and IMHO, impractical from a layered architectural perspective.

The fact is, process services, business services and technical services WILL all leverage intermediaries. This means that they all require direct access to that layer. As much as we (Momentum) would like to break them into separate layers, we can't do it without significantly violating the rules of the layered architecture. The solution that we landed on was 'embedded layers'. Here, we create a service network view which has a pure layered approach. Then the types of services are once again layered. And lastly, the pieces of a single service are layered.

The following diagram is part of the Momentum Web Service & SOA Reference Architecture:


I believe that this diagram depicts the intent of the IBM architecture without violating the constraints of the architectural patterns.