Within the context of Enterprise Architecture and business transformation, Service-Orientation is a concept that many are still grappling with (predominantly because of the confusion whipped up across the industry caused by the overhyping of SOA Infrastructure and an association with a particular style of web service). However, the concept of “Service” itself is not new, in fact it actually predates the concept of industry. Within my own experience, nevertheless, much of the dialogue regarding service orientation focuses on the narrow aspect of delivering software services that provide integration points between software applications in a reusable manner, and increasingly, the exposure of services to the web (within a Web2.0 context). Consequently, the unit of “Service” is often treated as a new revolutionary enabler for the Enterprise rather than the evolution of a concept that pre-dates the industrial revolution let alone the information revolution.  Adopting a means of modularising the IT estate and the enterprise through a “Service-Oriented” style and exposing (or consuming) Software as a Services on the web is of course a quantum leap for Enterprises that want to increase efficiency and innovation. However, there is probably much more potential for lessons to be learned from the management of Services in the traditional sense within the sphere of Service-Orientation than currently are.

Within the traditional sense, Services are considered as the “outside-in” where the outside is the customer base and thus the design of the service is done so from a consumer perspective. Ditto for Service-Orientation (well, probably not universally, but in a highly mature Service-Orientated Enterprise this should be the case!). However, in the traditional management of services there is an extra level of sophistication that is not apparent in the field SOA.  Market Forces.

The concept of a market and therefore market forces have not truly emerged as a component of Service-Orientation because the focus (traditionally) is internal rather than external. It isn’t that the market doesn’t exist however, it’s more that the market is one (the enterprise) and therefore studying market forces appears to be irrelavent. However, this assumption breaks when the enterprise wishes to expose it’s (traditionally internal) enterprise services to the web.

Taking a consumer perspective of SOA Services within the heartland of the enterprise means tailoring the dialect to another part of the enterprise and the nature of the service exposure is driven by overall business drivers such as consistent business processes and customer service and increased time to market. Consequently the service is required to enable a complex array of business change scenarios such as business process, portfolio, market segment, customer sector, geography, etc with minimum or no development. For example, an order management service would need to support change in all of these dimensions without a need to change the underlying order management service. The nature of these services is that they provide an incredible amount of flexibility to the business – but at a cost. The nature of the service exposure for such services is one of a large amount of (necessary) optional information which increases complexity and reduces accessibility to the masses.

Conversely, at the periphery of the enterprise where Enterprise Services are exposed to the web as Web2.0 Services and Applications, simplicity is king. The optionality provided internally to the business needs to be abstracted to provide a limited number of options to enable the mass market of developers and users of the web to consume the service without a detailed knowledge of the inner workings of large enterprises (e.g. without a “PhD in billing”).

So, what happens is an impasse where the development teams at the periphery of the enterprise argue that the enterprise’s services are too complex and the teams working within the heart of the enteprise argue that the team at the periphery are over-simplifying.

Is the truth that they are both correct? Is it not the case that both teams are working from a consumer perspective but the nature of the consumer is different? One team looking at the market needs of business divisions that have to support a large array of products, customer sectors, geographies to manage, the other the needs of a mass market? Is it also not feasible that actually these two positions represent the two ends of a spectrum with a large multinational corporation on one side (the tall head) and individuals and sole traders on right (the long tail). Is it feasible that the degree of abstraction (“hurray, I’ve used the word at last”) provided by services might need to be tailored according to the position of the customer base on this curve and therefore for any one service multiple exposures at different levels of abstraction might co-exist for different markets? Is Service-Orientation now being driven by market forces?

I’ve been watching with interest the following debates regarding the “SOA”acronym..

• http://weblog.infoworld.com/realworldsoa/archives/2008/02/soaaby_any_othe.html
• http://blogs.progress.com/soa_infrastructure/2008/02/soa-we-got-the.html
• http://www.enterpriseagility.dk/?p=14

Fascinating and comical but surely it IS the acronym and name that causes so many of the problems  associated with the common misunderstanding and misinterpretation of what Service-Orientation is and isn’t. Similarly (as per my previous post) one of the barriers to winning the hearts and minds to an architecture is the word “architecture”

I concur completely that SOA and EA are converging. The biggest benefit of Service-Orientation is the modularisation of organisations rather than just IT. If we focus the acronym and name to reflect this then would this:-

1. Provide a name that is more meaningful to the business?
2. Focus the name on the “Orientation” rather than the “Architecture”?
3. Remove the perception that SOA is related to SOAP based Web Services?
4. Stem the over-hyping of proprietary and heavyweight middleware products? (it’ll be much more of a challenge for vendors to sell a middleware product as an enterprise than an architecture!!!)

Come on lets treat this subject with a bit more respect. In fact to demonstrate my passion for resolving this. Future posts to this blog will no longer use the acronym SOA…

SOA – A + E = SOE?

I picked up this great little tip today…

The key to influencing people (business and IT)  of the benefits of, and securing buy-in to your enterprise architecture….

…don’t mention the words “enterprise” or ”architecture“.

Despite many posts out there in the blogosphere that make it clear that SOA is an ethos (or even a journey) rather than a technology I’m still amazed at the level of misunderstanding that still exists. There is no W in SOA yet many still confuse SOA with an architecture of WS.* style Web Services. Only today a representative from an apparent leading SOA Governance vendor talked to me about their product’s ability to support SOA and other types of service. ”Service” simply means that a Party or Thing consumes an experience that delivers a specific goal, be it a desktop application, a thick-client application, web-based application and exposed via WS/SOAP, Rest, a Widget or a desktop application’s user interface. In fact as the concept of service pre-dates software, even a manual paper-based process exposed via a fax machine or telephone provides a service, and as such a SOA could be delivered without any software.  No web services, no app servers – just people, paper and process. The decomposition and encapsulation of the business processes into services would enable their business to re-use the people, paper and process consistently and to build services from other services that could be consumed internally (services not visible to customers) within the business or externally (the services that are visible to customers) in a modular fashion.

It is however the inclusion of technology (in particular software and web technology) into the contributing parts of the delivery mechanism for the service where the ultimate power to the enterprise is. But you can’t conversely deliver the benefits of a SOA to an enterprise by simply defining XML messages using WSDL and using SOAP envelopes and putting them into a registry. They can only be delivered from a combination of an outside-in business perspective (or “Service-Orientation”) and good software engineering practices (which it inevitably necessitates).

In my previous post I appeared to be critical of the IT industry. The IT industry however, is a fabulously diverse and rapidly evolving one that is re-shaping how people interact (see “Generation M“). In particular the dynamic between the individual and the enterprise is changing through the empowerment of individuals to publish and to leverage IT applications in new and exciting ways from creating there own businesses through eBay, selling their own products on Amazon to creating Facebook Apps, building applications on top of Amazon Db and MashUps. Truly amazing. So on one side of the spectrum the industry is creating simple building blocks that enable the individual to innovate. But on the other we have many business software vendors continuing to sell monolithic and inflexible applications that focus on a subset of the business need creating a massive market in various families of middleware products that are making it difficult for the enterprise to innovate and create the enterprise architecture it desires because the focus for the enterprise is still one of systems integration. Of course, Service-Oriented Architecture (a topic I will post on soon, I promise) is heralded as the means to decompose the monoliths into functional blocks but to too many SOA means little more than an IT exercise of exposing proprietary APIs via a WS.* style web service from the monoliths and having a central registry of them rather than true Business/IT alignment through the engineering of various layers of semantically-rich services that empower the enterprise to build the an architecture that truly delivers to their business strategy and that facilitates the type of innovation available to the individual via the web.

To be continued…

I work in the Chief Architect’s office for a large multinational technology company. We don’t have a Chief Information Officer because the role goes beyond just IT, we’ve centralised the architecture of how the company leverages technology (software and hardware), people, process and information into one place so that we can develop a holistic “Enterprise” Architecture, so I now call myself an Enterprise Architect.

The role of an architect within the IT industry grew from a growing recognition that when a company allows it’s numerous IT programmes to buy and build it’s own software applications without a clear “architectural” direction, the result can be that the company can end up as a corporation equivalent of the Winchester Mystery House - and many companies have indeed been very successful in achieving this. So the rookie IT industry stole the concept of an architect from the very established building industry and the demand for IT architects and software architects snowballed as a consequence.  As the role of the IT architect began to become clearer frameworks such as the Zachman Framework and TOGAF began to point out that the real architecture to worry about is that of the business itself rather than just a collection of integrated IT applications. Soon architects needed to worry about process, people, technology and even, information (I’ll explain my cynisism directed at the Information Technology industry for its disregard for information in subsequent posts).

However, if you take a step back from these very positive move towards the very noble goal of enterprise architecture to compare the role of an enterprise architect with the building architect however you begin to notice some stark differences between the maturity of the building trade and the IT trade that skew the equivalence of the role.

In the building trade builders use various degrees of assemblies (from raw materials such as mortar, to basic building blocks (bricks) to windows and frames right through to prefabrications) and the builders have very basic principles and flexible techniques for constructing the architect’s vision from them. In the IT industry the builders themselves sell pre-built and pre-furnished rooms. The dimensions to the rooms do not conform to any previously specified plan, the decor might not be quite what the customer wanted but most importantly the different rooms don’t fit together because they’re different shapes and sizes and the position of the doors don’t correspond with each other.

The role of the Enterprise Architect therefore is dominated by:-

•  the challenge of building a magic corridor that brings all of the disparate rooms together and allows people pass through the doors as if they were all consistently located.
• Attempting to decompose the prefabricated rooms into underlying components to in a vein attempt that the individual components could easily fit into the building more easily and that a subset of a prefabricated room’s construction can be used in isolation without it collapsing.
• Building a facade of walls, windows and doors around the random assembly of rooms to make it look like a consistently functioning building from the outside

And the IT industry response to these challenges?

1) Sell kits to construct the facade

1) Continually sell generation after generation of magic corridors…

2) Offer to architect the whole building for you from a random assembly of prefabricated rooms and their own magic corridor.