img
ServiceTechMag.com > Issue LVII, December 2011 > Architecting Service-Oriented Technologies

Bookmarks



ARCHITECTING SERVICE-ORIENTED TECHNOLOGIES

Published: December 14, 2011 • Service Technology Magazine Issue LVII PDF
 

Abstract: This article discusses how TOGAF, UML, and Agile/XP can help build service-technology architecture.



Figure 1 - Lewis Carroll's Cheshire Cat.

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.

Alice's Adventures in Wonderland (1865)


Introduction: Three Challenges

The enterprise service technology architect faces three challenges. The architect must model complicated existing systems and new service technology architectures (STA), promote STA to stake holders throughout the enterprise who vary widely in engagement, commitment, and knowledge, and realize the vision of that STA. Only three challenges? Of course, these are only a few of the many problems that plague the architect. But most issues have their roots in these three challenges.

The purpose of this paper is to suggest practical approaches that can address these concerns. A purist approach to architecture will deliver results, but we want to consider whether we can get the same results more quickly and more cheaply. We’ll answer these questions in the following sections:

  1. Complexity - Modeling Cats and Pencils
    - How can we model complexity at the right level of detail and abstraction?
  2. Communication - Design Elements
    - What are the building blocks of STA?  
  3. Execution - Organizing for Success
    - How can we foster velocity and quality in building STA solutions?

Modeling Cats and Pencils

When we design service technology architectures, we must accept that we have mental blinders. Consider, for example, the house cat. What is it? We could start by listing its properties: it’s a small, furry, cleanly, carnivorous mammal attached to both places and to people. Let’s now say that we have an ideal definition that has all properties that give all of the necessary and the sufficient conditions to qualify as a cat. Have we defined a cat? Enterprise architects deal with semantics in the broadest sense, so the answer to this question is important. The answer is: no. The internal structure of a cat, its true essence or fundamental ontology, its “cattiness”, may be hidden from us and await discovery or might exist but may never be discovered. This agnosticism should inform our drive to understand any system.  

Leonard E. Read, in his 1958 essay “I, Pencil” makes an audacious claim: “I am a lead pencil — the ordinary wooden pencil familiar to all boys and girls and adults who can read and write. Simple? Yet, not a single person on the face of this earth knows how to make me” [REF-1]. He breaks the pencil into its various parts and then traces back the ancestry of each of those parts. “Actually, millions of human beings have had a hand in my creation, no one of whom even knows more than a very few of the others. There isn’t a single person in all these millions, including the president of the pencil company, who contributes more than a tiny, infinitesimal bit of know-how” [REF-1]. Read uses the pencil as a cautionary parable against the pretense of planning omniscience. He says that our error is not to plan big – it’s to plan big without humility. Certitude is the great enemy of STA success.

We deal with entities such as cats and pencils and attributes such as whiskers and wood. But we must accept as a given that there are questions without answers and that a true understanding of any entity will elude us, as there are limits to thoughts and symbols. The cat and the pencil teach us that we must cope with unfathomable unknowns. But in this realm of mystery, we must act. And we do so with the help of frameworks.

A framework is a blueprint that lets us envision, plan, develop, test, deploy, and stabilize architectures. It’s a device for building systems despite our limits of understanding. A framework leverages the countless years of experience of other enterprise projects. The tool kit of an architect has many frameworks. For software development, there is Agile/Extreme Programming (XP). Process methodologies include CMMI, ITIL, and Zachman. We can use other frameworks for enterprise modernization and transformation, governance, security and compliance, project assessment and remediation, and architecture evaluation.

For those engaged in service technologies, the two most important frameworks are the Open Group Service Integration Maturity Model (OSIMM) and The Open Group Architecture Framework (TOGAF). Who should be trained on such frameworks? The answer is everyone on both the business and the technology side that has any part in the development of STAs. The progression of certification should be top down in the hierarchy and from left to right in the process stream.


The Open Group Service Integration Maturity Model (OSIMM)

OSIMM lets us assess an organization’s SOA maturity level. It defines a process to create a roadmap for incremental adoption that provides clear business benefits at each stage. OSIMM is a quantitative model to help evaluate the current and future state of SOA maturity. The OSIMM matrix has maturity levels as columns progress from left to right, and the different organizational dimensions are represented as rows: business view, governance and organization, methods, applications, architecture, information, and infrastructure and management.

To learn more, see Appendix A.


The Open Group Architecture Framework (TOGAF)

TOGAF is an enterprise architecture framework. It answers the question: How can we build systems to achieve business goals? TOGAF addresses four key concerns:

  • Business Concerns - business strategies, organizations, and processes
  • Application Concerns - applications to be deployed, their interactions, and their relationships to business processes
  • Data Concerns - the structure of physical and logical data assets of an organization and the resources that manage these assets
  • Technology Concerns - issues of infrastructure and middleware

TOGAF’s Architecture Development Method (ADM) is an iterative process to develop these architectures. TOGAF, as it relates to STA, makes adjustments in the requirements management phases [REF-2].

To learn more, see Appendix A.


United Modeling Language (UML)

UML is a notation language that provides a syntactic framework to express common design decisions using a framework such as TOGAF. UML includes the following diagrams:

  • Structure Diagrams include the Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram
  • Behavior Diagrams include the Use Case Diagram, Activity Diagram, and State Machine Diagram
  • Interaction Diagrams, all derived from the more general Behavior Diagram, include the Sequence Diagram, Communication Diagram, Timing Diagram, and Interaction Overview Diagram

Architects can model STA with UML [REF-3].

The main problem with UML is that it's jargon. It’s a vocabulary that an architectural priesthood uses but few others understand. Our goal must always be communication, cooperation, and cohesion. UML eases understanding between peers. But, like barnacles that need to be scraped from a ship, clarity may require that we rid ourselves of excessive UML affections. We must strive for simplicity by turning UML models into simple lines, simple shapes, and simple declarative sentences. We work with complexity. That pressures us to create complexity. But the antidote to complexity is simplicity. Simple words, in particular, can be powerful in overcoming resistance to a new path. Basic events require simple language. "Strike three". "You're overdrawn". "You have the account". "Mother's dead". "Yes". "No". The path to that kind of simplicity is often hard but it's simplicity that persuades. David Belasco, the great American theatrical producer, once said, "If you can't write your ideas on the back of my calling idea, you don't have a clear idea."

Michael Hugos, principal at the Center for Systems Innovation, describes UML as a Victorian novel where the trivial and the critical are lost in a blur of details [REF-4]. He proposes that five diagrams can support almost all software engineering. These are: process flows, logical data models, a presentation layer design, a systems architecture diagram, and a software object model. "These five diagrams represent a clear and comprehensive set of specifications. Because the diagrams are easy to understand, your business users can join your technical staff in effectively designing and developing any new system. The result is a much higher success rate on development projects than is possible using that rambling mass of words and abstractions called UML" [REF-4].

The fishbone (or Isikawa) diagram is also a graceful bridge for business users who can quickly grasp the part-to-whole or cause-and-effect relationships.


Figure 2 - Fishbone Decomposition Model

In Figure 2, the “effect” is the result of four separate causes or factors that contain eight additional conditions. The fishbone can help deconstruct chains of causality and state transformations or analyze the relationship of components within systems. It promotes clarity by forcing the modeler to compress descriptions of causes or parts into one or two word labels.

Design Elements

STA design elements consist fundamentally of principles and patterns.


Principles

A principle is an imperative standard. “Fasten your seat belt”, “honor your parents”, and “be neighborly” are principles. They come from common sense and from our shared humanity. Principles are also a priori propositions, reasonable perhaps but not provable. For the logical positivists of the 1930s, if we couldn’t verify a statement empirically, it was literally nonsense. But this criterion is, in itself, a principle. Some principles, such as “science is” and “faith is” on the surface seem to contradict each other while other principles, such as “free speech” and “public safety” suggest that an absolutist application of either principle can undermine both principles.

If we fall short of the principle, the principle remains but so does our failure of that principle. An application, by contrast, is a way to meet the principle. We could think of a principle as a destination. Let’s say we want to go from New York City to Chicago. We could drive, fly, go by train, take expressways, or take the scenic route. Chicago is the principle. The way we get to Chicago is the application. If our journey ends in Cleveland, we’ve failed our principle of going to Chicago. If the principle is to have a daily scrum and our standup is on Monday through Thursday only, then we have failed the principle. Java, .NET, SOAP, and REST are applications of principles, not principles.

Service technology's principles come from thought leaders and from project experience. The following principles define service orientation [REF-5].


Principle Imperative Standard
Standardized Service Contract “Services within the same service inventory are in compliance with the same contract design standards.”
Service Loose Coupling “Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment.”
Service Abstraction “Service contracts only contain essential information and information about services is limited to what is published in service contracts.”
Service Reusability “Services contain and express agnostic logic and can be positioned as reusable enterprise resources.”
Service Autonomy “Services exercise a high level of control over their underlying runtime execution environment.”
Service Statelessness “Services minimize resource consumption by deferring the management of state information when necessary.”
Service Discoverability “Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.”
Service Composability “Services are effective composition participants, regardless of the size and complexity of the composition.”

Table 1

Let these principles guide your service technology architecture.

It’s a mistake to build an architecture based on an application of principles rather than the principles themselves. The reason for this is that it puts us into a position of chasing or locking in technology rather than driving towards business goals. Further, we can stray from service technology that supports business goals. For example, a valid pattern for an Enterprise Service Bus is point-to-point integration, where messaging flows from adaptor to transformation to adaptor. That approach is easy but it isn’t service loose coupling. Alternatively, a canonical modeling pattern allows us to dynamically add subscribers and provides cross domain value mapping (DVM). A routing service pattern also provides decoupled flexible routing with services visible to Business Process Execution Language (WS-BPEL), a Business Activity Monitoring (BAM) service, or Web Service Management (WSM).

A net catches a fish, a chef cooks that fish, and the patron’s money goes to the restaurateur. The end of catching the fish becomes a means of enriching the restaurant. In the same way, the principles of service technology become an application to the principle of commercial success. A higher principle must be the basis for abandoning or moderating a lower principle. An enterprise’s highest principle is to make money. Our operating principle shouldn’t be purism or pragmatism but profit. If service technology is a means to that end, then there may be other means to that end. For example, a closed source platform might meet business goals more effectively than by building an open source platform. One approach may be more flexible while the other is more lucrative. We should determine in the context of our time box, budget, and business objectives what is gained or lost by how we embrace service technology principles. But the decision not to use certain STA principles is still an STA decision.


Patterns

A design pattern is “a proven solution to a common design problem documented in a consistent format” [REF 6]. A design pattern describes “a common problem and provides a corresponding solution. It essentially documents the solution in a generic template format so that it can be repeatedly applied.” Design patterns come from project experience. “Pioneers in any field had to undergo cycles of trial and error and by learning from what didn’t work, approaches that finally did achieve their goals were developed. When a problem and its corresponding solution were identified as sufficiently common, the basis of a design pattern was formed” [REF-6]. Different design patterns can be combined into compound patterns and can address the same need. We can think of architecture as a house and design patterns as components that make up that house, such as the rooms, the appliances, and the wiring.

Here is an example of a service technology pattern [REF-7]. A rich and growing supply of other SOA patterns are available for our use [REF-8].


Dual Protocols
Question How can a service inventory overcome the limitations of its canonical protocol while still remaining standardized?
Problem Canonical Protocol requires that all services conform to the use of the same communications technology. However, a single protocol may not be able to accommodate all service requirements, thereby introducing limitations.
Solution The service inventory architecture is designed to support services based on primary and secondary protocols.
Application Primary and secondary service levels are created and collectively represent the service endpoint layer. All services are subject to standard service-orientation design considerations and specific guidelines are followed to minimize the impact of not following Canonical Protocol.
Impacts This pattern can lead to a convoluted inventory architecture, increasing governance effort and expense, and (when poorly applied) an unhealthy dependence on Protocol Bridging. Because the endpoint layer is semi-federated, the quantity of potential consumers and reuse opportunities is decreased.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction, Service Autonomy, Service Composability
Architecture Inventory, Service

Table 2

This outline doesn’t explore the implications of the Dual Protocols pattern and its synergy to service technology principles, but it does suggest how we define a pattern.

As new technology emerges, we’ll see new design patterns. However, reaching new principles is less likely unless a new architectural paradigm supersedes the old paradigm.


Organizing For Success


Two Rules

A principle of governance is that we should promote a few rules with no exceptions rather than a plethora of rules with many exceptions. Realizing a successful STA reduces to a one basic task and one basic principle:

  • As a task, mandate a daily scrum
  • As a principle, make more than one person accountable for any one deliverable

From Agile Development, we borrow the accountability and communication that a daily scrum offers. From XP, we borrow the quality and velocity that pair programming offers. These are fundamental as they buttress the higher principles of transparency, communication, quality, and velocity that enable STA success.


Social Engineering

The best architects, be they of bricks or of bytes, envision great and far-reaching things. “Make no little plans,” Daniel Burnham, the 19th century Chicago architect said. “They have no magic to stir men's blood and probably themselves will not be realized. Make big plans. Aim high in hope and work, remembering that a noble, logical diagram once recorded will never die, but long after we are gone will be a living thing, asserting itself with ever-growing insistency. Let your watchword be order and your beacon beauty. Think big” [REF-9]. STA lends itself to this sweeping vision of greatness. Timid half measures are a kind of myopia. STA doesn’t merely promote mobility, cloud computing, social media, RESTfulness, the semantic web, and analytical intelligence. It transforms the enterprise to a higher and better level. But planning isn’t enough. We must realize those plans. And we do that through social engineering.

Social engineering negatively connotes subordinating people to processes and regimenting people to get results. But this half-truth contradicts the record that those who successfully adopted social engineering did so without compromising their humanity. For example, Henry Ford’s assembly line grew out of the work by Frederick Tailor a generation before. Ford, as well as similar companies in Europe and Asia, produced an automotive power house by using scientific management that attracted labor in the open marketplace.

The staff won’t resist social engineering. It will thrill the trainee with exposure to new technologies and ideas. In-house experts – those with five to ten thousand hours of expertise in SOA, messaging, ETL, or open source tools – will also be the shining stars in this firmament and will be rewarded accordingly. But the dinosaurs will sense that their day is passing and they will fight to preserve their Jurassic world. They cling to roles that exclusively face either business or technology and also lack the passion for communication, collaboration, and adaptability that is needed to make this paradigm work. Often, the company’s elder statesmen – people with skill, experience, and charisma – will undermine service technology efforts that need their leadership. The reasons may be psychological or political, but the effect of these gatekeepers can be devastating and it accounts for much of the intractability of a company’s willingness to embrace change. If we accept the principles that the greatest good is for the greatest number and that well-run companies don’t have tenure, then there are just two choices: either they change or they leave.


From Daisy Chains to Surgical Teams

Projects often fail because the organizational structure constricts the flow of information that facilitates project success. Consider the number of hand-offs taken between that first glimmer of insight and reaching a money-making initiative and then to the final realization of the idea months, or sometimes years, later. At some of these nodes, there may be a single individual, for example, a manager or a systems analyst. But, as the number of nodes increase, the quality of communication erodes. Written requirements may suggest understanding. But much of the context, from e-mail and instant messaging threads to teleconferencing and hallway conversations – is gone. All that remains are well-written documents that have little to do with what the business envisioned.  

To solve the problem of communication decay, we must replace daisy chains of specialists with interlocking teams of experts much like you would see in a hospital.



Figure 3 - Workflow Models



Figure 4 - Workflow Models

In Figure 3, the high risk model (A) is characterized by a string of people. One systems analyst might deliver one document to one architect who creates another document that is sent to a developer. The process might consist of three dozen nodes—a long and inefficient journey. By contrast in Figure 4, in the low-risk stream (B), the number and thus the points of failure are far less than in the high-risk stream because the information flow is broader and shorter. The people in red represent a duplicated role on a separate team to enforce cross-team integration.

The 18th century Scottish poet Robert Burns was sitting behind a young girl in church when he saw a bug scamper over her bonnet. In his poem “To a Louse”, he wished for the gift of stepping outside of ourselves to see what really is:

It wad frae monie a blunder free us,
An' foolish notion: 

[REF-10]

The blunders, foolish notions, false assumptions, and other bugs that find their way into our STA are nurtured in the kind of arrogant obliviousness of which Burns wrote. The answer lies in mutual ownership where one person owns nothing and the team owns everything.

This concept isn’t new. At the peak of most corporations is a board of directors in which the whole, in terms of understanding, is greater than the sum of its members.  But the effort to scale such structures down and across the enterprise, so that work flows from the synergies of a master mind rather than from individual craftsmen, is relatively new. Its goal is to enhance productivity by shattering the atomization, isolation, and solipsism—the subjectivism that what one expert apprehends must be reality – that prevails in software engineering.

Specializations remain. Modelers would still model and developers would still develop. But this effort would now take place with accountability to someone else, to their scrum team, and across the enterprise. No longer could one person be a bottleneck as there would be enough shared knowledge to resolve issues immediately. Two or more people would be accountable for developing a business case or a requirements document or a WSDL or any other deliverable. The larger team would have small teams but there would always be teams rather than individual contributors. That dyad could consist of two or more junior people, two senior people, or a junior person and a mentor. There is no reason why such people could not be co-located, have different titles, or work different shifts. It’s a dynamic, entrepreneurial process where leadership is pushed down and each sub-team is empowered to get results as they wish – so long as they do get results.

Software engineering tasks have typically followed a delegation of duties without this kind of accountability, and the result has been an unevenness of quality and slippages in performance. Thus, if we had two developers who had to write four functions, one developer would write two functions and the other developer would write two functions. Under this approach, two developers would be accountable for the four functions. It may be that one developer would code all four functions, but this would happen in the context of clearing the way, getting resources and understanding, along with doing quality reviews, debugging, and testing which would be completed by the other developer. Such an approach reduces rework, enhances quality, ensures compliance to deadlines, and aligns with Agile/XP principles.


A Daily Scrum

To make this process work, a daily standup is an iron law. The meeting will be about 15 minutes. If there is an offshore component, we should schedule it in the first or the last hour of the day. The scrum master will ask everyone three questions:


Question This Means
“Last 24?” Tell us what you’ve done in the last 24 hours to meet the daily goals of the current sprint.
“Next 24?” Tell us what you plan to do in the next 24 hours to meet the daily goals of the current sprint.
“Problems from the floor?” Tell us what issues need the team’s attention today.

Table 3

This routine will expose issues rapidly and motivate team members to track to management's goals.


The Human Dimension

That enterprise-level projects fail often has little to do with the availability of talent. To the contrary, Frederick Brooks’ observed in The Mythical Man-Month: Essays in Software Engineering that too much manpower will delay and sometimes destroy the project. Brooks wrote "Question: How does a large software project get to be one year late? Answer: One day at a time!" [REF-11]  This staffing model can identify those incremental slippages that in the aggregate produce failure. It can be applied to developing and deploying STA software in such a way as to significantly reduce software costs and risk and increase time-to-market and quality.

Working in tandem on a common task creates opportunities for professional growth as well as opportunities for personal conflict [REF-12]. It’s a challenge for those who cannot work with other people because of their ego or for other reasons. But most people are wired to respond socially to others in such a way that they will do whatever it takes to see that their mutual goals are met. It will take commitment, sacrifice and, above all, leadership. “Success is achieved through high caliber people with a storehouse of knowledge covering all facets of development, and with a willingness to share,” Christopher Coyle notes. “It’s imperative that all major business applications development involves tangible and visible leadership from the CEO. Teams require the very best people (this is a major sacrifice for any business). All involved need to be totally honest (such as, I don't know, I can't deliver, what you are asking is impossible)” [REF-13].

Companies are at war with themselves. Armies of engineers and armies of sales people clash for dominance. When engineers prevail, we can have solutions that miss their market. When sales people prevail, we can have solutions that have lost their magic.


  Information Technology Marketing
Role Engineering Solutions Selling Products
World View Purism Pragmatism
Guiding Principle “Do it right” “Do it now”
Goals Innovation and Quality Profits and Market Share
Strengths Vision and Discipline Customer Astuteness and Responsiveness
Weakness Marketing Illiteracy Technical Illiteracy

Table 4

The architect is in the best position to bridge this divide by forging a partnership that is innovative and customer driven and that provides just-in-time architecture and solutions to a responsive marketplace. It’s the best of both worlds.


Conclusion: Throwing Away the Ladder


My propositions are elucidatory in this way: he who understands me finally recognizes them as senseless, when he has climbed out through them, on them, over them. (He must so to speak throw away the ladder, after he has climbed up on it.)  He must surmount these propositions; then he sees the world rightly.

[REF-14]


Ludwig Wittgenstein

Wittgenstein (1889-1951), an Austrian-born Cambridge don, was a co-founder of analytic philosophy and thought deeply about the limitations and paradoxes of semantics.  His expression of throwing away the ladder may relate to his principles, to principle itself, or to how we use principles. The great icons of architecture, such as the Taj Mahal, the Golden Gate Bridge and the Eiffel Tower, are great because of what they exclude. The most elegant and effective designs are often the most simple, as in the paper clip.


Figure 4 - Paper Clip, c. 1900
Wikimedia Commons

Developing service technology comes down to simplifying systems to meet enterprise goals and simplifying processes to reach those goals. We don’t disparage the effort it takes to master the tools that can help us craft a STA. But getting to where we want to go to might require that we abandon our old tools. TOGAF, UML, and Agile/XP are invaluable ladders. But there are times when we may need to throw these ladders away to see the world of services rightly.


References

[REF-1]  Read, Leonard E., “I, Pencil”, 1958.  http://www.fee.org/library/books/i-pencil-2/

[REF-2] The Open Group, “Using TOGAF to Define and Govern Service-Oriented Architectures”, 2011, pp. 47-52. https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g113

[REF-3]  Rao, Prithvi, “Using UML Service Components To Represent the SOA Architecture Pattern”, IBM.com, June 2007.

[REF-4]  Hugos, Michael H., “Five Diagrams Beat A Victorian Novel”, ComputerWorld, September 24, 2007, pp. 23.

[REF-5] Erl, Thomas, SOA Principles of Service Design, Prentice-Hall, 2010.

[REF-6] Erl, Thomas, SOA Principles of Service Design, Prentice-Hall, 2010, pp. 31.

[REF-7] Erl, Thomas, SOA Design Patterns, Prentice-Hall, 2010, pp. 227.

[REF-8] Erl,Thomas, SOA Design Patterns, Prentice-Hall, 2010, chapters 6 - 21.


Service Inventory Service Inventory Sub-Category Service Inventory Design Patterns
Foundational Inventory    
  Inventory Boundary  
    Enterprise Inventory
    Domain Inventory
  Inventory Structure  
    Service Normalization
    Logic Centralization
    Service Layers
  Inventory Standardization  
    Canonical Protocol
    Canonical Schema
Logical Inventory Layer    
    Utility Abstraction
    Entity Abstraction
    Process Abstraction
Inventory Centralization    
    Process Centralization
    Schema Centralization
    Policy Centralization
    Rules Centralization
Inventory Implementation    
    Dual Protocols
    Canonical Resources
    State Repository
    Stateful Services
    Service Grid
    Inventory Endpoint
    Cross-Domain Utility Layer
Inventory Governance    
    Canonical Expression
    Metadata Centralization
    Canonical Versioning
Service Design Category Service Design Sub-Category Service Design Patterns
Service Identification    
    Functional Decomposition
    Service Encapsulation
Service Definition    
    Agnostic Content
    Non-Agnostic Context
    Agnostic Capability
Service Implementation    
    Service Facade
    Redundant Implementation
    Service Data Replication
    Partial State Deferral
    Partial Validation
    User Interface Mediator
Service Security    
    Exception Shielding
    Message Screening
    Trusted Subsystem
    Service Perimeter Guard
Service Contract    
    Decoupled Contract
    Contract Centralization
    Contract Denormalization
    Concurrent Contracts
    Validation Abstraction
Legacy Encapsulation    
    Legacy Wrapper
    Multi-Channel Endpoint
    File Gateway
Service Governance    
    Compatible Change
    Version Identification
    Termination Notification
    Service Refactoring
    Service Decomposition
    Proxy Capability
    Decomposed Capability
    Distributed Capability
Service Composition Category Service Composition Sub-Category Service Composition Design Category
Capability Composition    
    Capability Composition
    Capability Recomposition
Service Messaging    
    Service Messaging
    Messaging Metadata
    Service Agent
    Intermediate Routing
    State Messaging
    Service Callback
    Service Instance Routing
    Asynchronous Queuing
    Reliable Messaging
    Even-Driven Messaging
Composition Implementation    
    Agnostic Sub-Controller
    Composition Autonomy
    Atomic Service Transaction
    Compensating Service Transaction
Service Interaction Security    
    Data Confidentiality
    Data Origin Authentication
    Direct Authentication
    Brokered Authentication
Transformation    
    Data Model
    Data Format
    Protocol Bridging

[REF-9] “Daniel Burnham”, Wikipedia, http://en.wikipedia.org/wiki/Daniel_Burnham

[REF-10] Burns, Robert, “To a Louse”, http://www.worldburnsclub.com/poems/translations/552.htm

[REF-11] Brooks, Frederick, The Mythical Man-Month, Addison-Wesley, 1975.

[REF-12] Wik, Philip, “Effective Top-Down SOA Management In An Efficient Bottom-Up Agile World”, SOA Magazine, April-May 2010, http://soamag.com/I38/0410-1.php

[REF-13] Coyle, Christopher, peer review, November 2011.

[REF-14] Ludwig Wittgenstein, Tractatus Logico-Philosophicus, 1922, 6.54. 


Appendices

Appendix A


Abbreviation Name Link
  Agile Alliance http://www.agilealliance.org/
CMMI Capability Maturity Model Integration http://www.sei.cmu.edu/cmmi/
ITIL The Information Technology Infrastructure Library http://www.itil-officialsite.com/
OSIMM The Open Group Service Integration Maturity Model https://www.opengroup.org/projects/osimm/
TOGAF The Open Group Architecture Framework http://www3.opengroup.org/aboutus
UML Unified Modeling Language
SysML
Model Driven Architecture
http://www.uml.org/
http://www.omgsysml.org/
http://www.omg.org/mda/
XP Extreme Programming http://c2.com/cgi/wiki?ExtremeProgramming
  Zachman http://zachman.com/about-the-zachman-framework


Acknowledgements

I wish to thank the following individuals who reviewed and critiqued my paper: Steve Wisner, Director, IT, Genworth Financial, Errol Ryland, Director, MSS Technologies, Inc, and Christopher Coyle, former Information Technology Director (retired), Colgate Malaysia/Singapore.