Book Review: Ladder to SOE
SOA is based on the premise of aligning business actions with software modules, the modules providing discrete services in support of the business actions. Too often, in practice, SOA is implemented almost exclusively as a technique for modularization, reuse, and establishing a software architecture. The connection to the business and to business processes - including the possibility of using SOA insights to re-engineer or optimize the business - is too often lost.
Michael Poulin's book, Ladder to SOE, focuses on the enterprise and how to use the concepts and principles of service-orientation to align IT and the business and raise new possibilities for convergent solutions to business problems. His goal is to provide a "ladder" a series of steps that lead to the establishment of the Service Oriented Enterprise - the organization constructed and operated on the principles of Service Orientation throughout Business and Technology.
Michael has provided two excerpts from his book as a companion to the interview below. Excerpt one shares some insights on how SOE can support business innovation and comes from Chapter Four of the book. Excerpt two comes from Chapter Seven and deals more more technical aspects of SOA and how the apply to SOE.
Some additional background and commentary on Michael's book is shared in this interview.
Michael, you argue that SOE and even SOBA are qualitatively different and more comprehensive that SOA. A lot of people would argue that SOA was intended to be just as comprehensive in scope and that there is no difference between the three terms. Are your arguments based on an analysis of SOA in theory or how that theory has been implemented in practice?
SOA was originally described as a service-oriented style of architecture in the technical sphere of knowledge. This certainly distinguishes it from SOE, which stands for service-oriented enterprise and from SOBA, which is used as either service-oriented business application or as business architecture. Thus, all three differ by at least the subject they are applied to.
As of comprehensiveness, it is a bit different story. I think that SOA as an architectural style did not have a chance to be properly understood before it was associated with a few technologies like Web Services, CORBA, and others. The storm of standards that followed the Web Services introduction actually shadowed the architecture and even obfuscated it so that many people started to believe that SOA and Web Services is the same thing while they are not. We have to distinguish between architecture and technology, which is used to implement that architecture.
It was a few years before the technology implementation practice under ‘SOA’ umbrella ‘hit the wall’ and was even proclaimed ‘dead’ in the instances where it fully substituted the architecture. This should not have been a surprise because technology promised results available only at the architectural level, i.e. technology simply was not capable to deliver on these promises.
In SOE or SOBA, the service orientation of business is placed in the centre and all implications are in the business area; architecture is the skeleton of the business at the enterprise level, not in the depth of IT. This service-oriented architecture has business and technical aspects but technology appears as one of the forms of the business implementation
SOE places everything in order. This is why it is more comprehensive than technical efforts to create services that consumers (operational business) do not recognise as being concentrated on the processes and procedures.
A true sense of partnership between IT and Business appears to be essential for SOE. Can you briefly indicate why such a partnership has been so difficult to achieve in the past and why you think SOE can succeed in establishing such a partnership?
Historically, IT developed as a support function in company’s business. This ‘supporter’ status did not change when we added PC to Mainframes and when technology moved from client-server model to the multi-tiered distributed structures. In the past few years it became obvious that in several industries technology became the fundamental part of traditionally manual businesses, that technology started to replace manual operations. Moreover, for industries dealing with trading, speed, accuracy, and quality of transmission and distribution of information became one of the major success factors. In other words, we have a clear indication that Technology ‘makes money’ whether the business likes it and agrees with it or not.
In SOE, the service-oriented organisational structure of the enterprise assumes that business and technology operate together, they serve each other, they converge. Otherwise, we cannot reach efficiency of business services in the market. Some organisations have recognised this new reality and started to treat IS/IT as partners. However, it is not a well-understood situation in the industry and I hope my book would help to progress in this direction.
Based on the best seller lists, Business seems to be obsessed with Change, with Innovation, with Adaptability and Agility where in previous decades they were obsessed with process, quality, and standardization. Why the change? Do you think that this will make the Business side more receptive to your SOE proposal?
Yes, you are right, there is a significant change in business objectives. I cannot explain an obsession with processes other than native human tendency to have instructions for every step and keep the brain fresh for fun. The processes and standardisation were suitable for the pace of market; market allowed such behaviour. As I mentioned before, the dynamics of the market have changed, accelerated and are now influenced by the global factors almost as much as by the local factors. These, I think, are some of the key drivers for Change, Innovation and Adaptability.
SOE capitalises on the potential of service-oriented model to compose, re-compose and decompose services to address changes in the external and internal environment. That is, service orientation is one of the best mechanisms for adaptation to changes and, respectively, for business innovations. I have a chapter in the book dedicated to this topic.
A lot has been written about the "Agile Culture" and how it differs from traditional IT cultures; e.g., in terms of different values, different attitudes towards human elements and teamwork, different emphasis on outcomes, etc. Can you compare SOE culture with Agile culture and address how you think you can get IT as a whole to undergo a cultural transformation?
It seems to me that when IT talks about ‘agile culture’ it is meant to be agile to the business requirements that are not necessary the same as the corporate business needs. This ‘agile culture’ is based on one notion: we are here, they are there. SOE preserves professionalism in business and technical areas but it erases the boundaries between business and IT, between them and us.
I can say that service orientation identifies the basis for business-IT agility or convergence in SOE. My conclusion is this - since business acts in the market providing services to the consumers (products are just results of the services), since business essence is expressed via services in the organisational business model and since principles of service orientation can be understood and realised in Technology, then service orientation is the cultural ground that both Business and Technology can stand on and share its values, views and spirit.
You talk about the need for appropriate simplicity and how hard it is to achieve. SOA is far from simple - it is large, complicated, and relatively fragile. How is SOE simpler? Is an enterprise a "simple" thing? Do we need a different perspective to guide our analysis of the business and of services before we can succeed in identify the correct set of simple, composable, services?
Well, SOA is as complex as the business it models. I do not think that consumer market is complex; the realisation of such market is complex. I have mentioned consumer market because in service-oriented eco-system the consumers ‘run the ball’ while providers are supposed to compete and struggle for the consumers (this has significant impact on the enterprise architecture landscape).
In the book, I argue that technical approach to services actually oversimplified the reality. With modern SOA, especially after OASIS SOA RM was released, we can address majority of complications and fragility of technical implementation, many of which were mistakenly attributed to SOA.
The method I use for identifying complexity of the services is based on the decomposition of the organisational business model. The top-level business services and a few processes may be consecutively disassembled into simpler services and processes until further disassembling does not make sense from the business point of view. I stop at this point because more granular services are only implementation technicalities and my potential consumer – the business – will never require them as they are out of the business domain. So, my advice is not to make things simpler than they are.
In chapter seven you present several key definitions and technicalities for services. You also talk about how these technical attributes of service interact. Could you talk a bit about the relative importance of these attributes and how emphasizing one over another might affect the ability to interact and be mutually supportive?
Yes, in this chapter I discuss service attributes such as Service Description, Service Contract, Real World Effect, Service Level Agreements, Execution Context and service orientation vs. service enabling. My explanations are based on the OASIS SOA Reference Model standard and a draft of upcoming OASIS SOA Reference Architecture (public review version). All mentioned attributes are examined from the service consumer perspective.
All attributes are important but they appear differently to consumers and to providers. For example, a service provider may maintain only one service but announce multiple Service Descriptions for different consumer audiences while each Service Description may be used to create many Service Contracts. Also, there are cases where the status of the service does not require agreements with the consumers, for example, a mandatory service like system security service. In this case, Service Description may be a default Service Contract to every consumer.
Can you trace any of the shortcomings of SOA (as it is practiced) to overemphasis of one service aspect or attribute over others?
When SOA was considered an integration technology, developers and even architects used to think about service interface as of a service contract with the outside world. I have to confess, I shared this understanding ten years ago. After SOA has crossed the border from IT into business, the role of technical interface has changed. The interface is still the most important element for technical interaction with the service but now SOA service is defined by the Service Description.
In spite of service implementation being hidden from the consumers, service business functionality and execution contexts must be described in the open as well as all applicable business and technical policies. A business service may have many different interfaces for different communication channels including direct human interaction interfaces - GUI. That is, overall public knowledge about the service is much wider than any of its interfaces can provide. In my book and in various other publications I am trying to convince developers to observe the service in full rather than exclusively concentrating on the interfaces. The behaviour and even business value of the same service could be changed due to applied policies without a change in the interface; this should not be our best-kept secret.
In chapter 13 you present a 21 step transition to SOE ladder. A ladder implies a fairly strict sequence of steps. Do you think that the 21 steps must be done in order? or is there some room for parallelism? Does the transition require that IT stops what it is doing, climb the ladder, and then proceed in the SOE way?
Not all steps to SOE have to be taken sequentially; some of them have to be passed at once, in parallel. I used word ‘ladder’ rather than ‘stairs’ or ‘way’ to outline that the steps have to be instrumented by an organisation, they do not exist on their own, independently from the climber. The ladder to SOE starts in the business, not in IT. Climbing into the service orientation requires several changes in the organisation, ownership, funding, operations and management before the transformation reaches IT.
The OMG recently announced a Business Ecology Initiative with IBM as founding sponsor. There is very little detail and substance to this announcement, but it seems to focus on the same kind of business-IT integration you are advocating? Is this a "sign of the times?" "the next big thing in IT?" Do you think that your work on SOE can make a significant contribution to the OMG effort (once we really understand what it is)?
I believe this is the ‘sign of the times’ as you said; we independently came to the same conclusion. My book describes one of possible ways of reaching the BEI goal - erasing boundaries between Business and IT. In the absence of more details on the BEI, I can’t say if the BEI would prefer the same solution as I described. However, if my approach helps BEI to progress, I would be only glad.
Is there any aspect of the book, or any argument in the book that you want to bring to the attention of the InfoQ audience?
Yes, I have one. I believe that in SOE the life of IT would become much easier and productive. It would also become less stressful and more predictable given that the business needs would no longer come ‘from out of the blue’. Instead, these needs would be commonly observed at an early stage due to a creative collaboration between professionals. As a result, companies would become more efficient and stable, with IT no longer treated as a mere cost centre. Rather, IT would become an active partner and a business solution provider.
Thank you Michael. Readers can learn more about Michael and his book on his website.
Ladder-to-SOE, book review
Ben Melbourne Jul 04, 2015
Randy Shoup Jul 03, 2015