I have not read many articles in SOA Magazine (Series Editor - Thomas Erl) where SOA was extended onto Enterprise Architecture and even Business. Nonetheless, the "Principles for Implementing a Service-Oriented Enterprise Architecture" by Tyson Brooks is one of them. I very welcome Tyson's efforts to position Enterprise Architecture (EA) in between Business and IT to cover both Business and Technical Architectures. I believe it is absolutely right position to be. Tyson says: "Extending the concept of SOEA beyond IT is a large and important step". To deal with this statement I need to understand what SOEA is; is it a part of EA, is it the EA itself, and so on.
I think, the most important step toward the answers to these questions is a close look at the "Key SOEA Strategic Principles". For the reader's convenience, I just copied the table below from the Tyson's article (instead of rephrasing principles in my own words):
In the comments to the table, Tyson says: "these SOEA principles serve as a bridge between the business and IT "layers" of the enterprise architecture. Organizational services are the foundation to support the reuse of applications, application capabilities, components, and business services. More importantly, well defined services help define SOEA concepts clearly". While I do agree with the first sentence, the other ones confuse me - I see some signs of the 'up-side-down' logic in them. Firstly, in the comments, the organisational services are placed into the leading position while the business services into the following one. Actually, in the enterprise reality, these types of business services occupy exactly opposite positions (but, from the IT 'basement' perspective, the organisational services are in front of the 'IT nose' while the business services are too far away). Secondary, IMO, reuse of applications and components is a pure IT's task, which does not exist at the enterprise level because it does not matter whether anything is reused whilst business functions execute as expected. Thirdly, "well defined services help define SOEA concepts clearly" is another bright example of 'the cart going before the horse' unless it is the SOEA specific. To my understanding, it is the very SOA concept that defines SOA services, not other way around; your service-oriented architecture is going first, and its realisation via services is going second. There are some other places like this in the article, unfortunately.
Tyson explains his principles one by one and I will follow him. To me, the principle "Services can include both business processes and IT services..." looks incomplete (if not inconsistent with the real organisation business model). I assume that words "Services can include" may be read as 'Business Service can include', but in this case why a Business Service cannot include another Business Service? If you look at the Business concept of any organisation from the top, the organisation business model consists of a set of Business Services and just a few Business Processes; the rest of the Business structure comprises business services of smaller scope and their implementation via business processes.
There are tow other aspects in explanations of this principle that have caught my attention as well. In particular, "IT-based services may often be implemented as Web services, but SOA is not exclusively about Web services; Web services are a specific subset of IT services"; we are getting into semantic mess here: we talk about automated and non-automated elements of a Business Service and call both of them 'services'. What is IT-based service? If I have a Business Service, which includes among others one another Business Service and one 'IT-based service', how I can answer following questions in the service oriented environment:
1) Am I sure that the included Business Service is 'pure' and does not contain an 'IT-based service' of its own?
2) Does an 'IT-based service' only a piece of software and does not include any process elements like workflow that engages some manual operations or even other Business Services?
3) If service orientation is really preserved in a business solution, does it make sense talking about IT-based vs. business-based services at all?
4) How a Web Service, which is defined via WSDL, can be a Service while WSDL define neither service's business functionality nor service's Real World Effect (RWE), i.e. Web Service is just an interface to the service and nothing more?
For the second principle - "Service Components are characterized by..." - its definition looks as a circular reference. I cannot resist asking: how much you are sure you are talking about Service Component if it poorly meets the definition of Service Component? What principle is this? So, we need to look into the explanations and they say: "... organizations should build complex systems, to the extent possible, from reusable service components. SOA encourages managers to break down established services into simpler components and determine if the components can be repurposed to the task at hand and enterprise architecture identifies all applicable services, systems, applications and technologies used within the organization". Well, with the reference to the first sentence, I argue that neither SOA nor any other methodology obliges organisations to build its systems "from reusable service components". First of all, it is up to the organisation to decide what to use for its systems and, second, looking at the organisation from the business perspectives, there is no so much reuse of the business components (actually, I do not know what Tyson means by 'reuse' and how it differs from the 'use'). I believe that "service reuse" is another pure IT concept and it is still not justified (why IT needs a Service to reuse something?).
Then, "SOA encourages managers to break down established ...." Wait a minute, since when managers became savvy in service orientation and breaking services into components and repurposing them? IMO, this is the root of majority of troubles in IT when a solution is "repurposed to the task at hand" by those who are not responsible for this solution and for its position among other solutions (when a shoemaker does the job of a blacksmith). In SOA, a task becomes 'a task at hand' only after it is reviewed by the Service Architects, i.e. after appropriate architectural solution is defined (when all necessary de- and re-compositions and repurposing are done); before this happen, the task is just a business concept or a request for change that is the subject for the business and technical observations. I am not saying that, e.g., project managers may not take existing services (service components) and repurpose them for the projects; on the contrary, this is much appreciated. I am standing against the "break down established services into simpler components"; what is looked as a 'simpler component' to a manager may appear as a terribly risky thing from the architecture point of view and may not be allowed in the company.
A talk about "IT or non-IT services as components that comprise one or more services" sounds strange to me - why we have to deal with components (which, by definition, are not services) while Service Orientation has the term for such compositions of services calling them Composite or Aggregate Services? I do not think we need new terminology in here. Also, a definition of a Business Component - "A BC represents the implementation of an independent business concept, business service, or business process. It consists of all the technology elements (software, hardware, and data) necessary to express, implement, and deploy a business concept as an autonomous, reusable element of a large information system." - is quite inaccurate, IMHO. How one can guarantee that given business concept is independent? Is this a reasonable assumption that the real Business Component consists only of autonomous (independent) services? Again, why Business Component must be reusable and why it should be an "element of a large information system" rather than an element of not that large one? I think the use of word 'component' in the article is very unfortunate and misleading.
Returning to the SOEA principles, I can say that the last two of them are not principles to me but rather the statements for the SOA Governance policies. Talking of which, I have to point to another Tyson's statement: "IT governance appears to develop best as a bottom-up response to need, rather than as a top-down imposition of abstract requirements. Since SOA is already taking root at the implementation level of IT, the governance of SOA may be able to grow effectively out of existing workgroups and management processes. Project and portfolio managers must communicate to senior managers and executives to develop an integrated list of the various services offered or planned" I would recommend Tyson to look into OASIS SOA References Architecture, coming second public review draft, or, at least, at my overview based on the first public review draft, to find what SOA governance is and what is should not be. The Best Practice in SOA Governance states that it is the Governance that defines what SOA Service is, how it has to be identified, architected, designed and implemented, where the SOA Service may be registered and how, as well as what tools must be used to develop and test the services in the organisation. All these are Enterprise level concerns; real Governance works only in one direction - top-down.
One of the SOA Governance goals is preventing wrong doing in the service implementation stage (considering that implementation still uses inappropriate methodology and practice inherited from the non-service oriented development past). Service orientation changes many aspects of SW development in IT including project/programme management, funding, testing environment and testing approach, management practice (service-oriented ITIL v.3 replaces management processes with functional activities). SOA Governance is based on the experience gained in bottom-up development of past years but growth from the top of the enterprise down to the project life-cycle dictating methods, technologies and controls that may and must be used in the organisation's Business and IT.
At the end, I have to confess, I have not understood what the differentiation is between SOEA and modern understanding of SOA as a methodology working across Business-Technology boundaries. Well, here is my guess where the core difference is: the business-oriented consumer-centric SOA has a mandatory requirement - service orientation must be started in Business and only then cascaded into IT while, according to Tyson, "Some organizations may be well along in implementing SOEA at the IT level". Oh, one step forward, two steps back, again...
Leave a comment