Book Excerpt and Interview: 100 SOA Questions Asked and Answered
A new "100 SOA Questions Asked and Answered " book by Kerrie Holley and Ali Arsanjani provides a deep insight into SOA covering a wide spectrum of topics from SOA basics to its business and organizational impact, to SOA methods and architecture, to the future of SOA.
In their new book "100 SOA Questions Asked and Answered”, Kerrie Holley and Ali Arsanjani provide a comprehensive SOA guide in a form of questions and answers about SOA. It is packed with challenging questions from business and IT stakeholders and provides corresponding answers, some of which are prescriptive and provide a base roadmap for potential implementation.
The book is organized in 10 chapters:
- “SOA Basics” defines service orientation and SOA and examines several SOA myths and misconceptions
- “Business” examines the business drivers behind SOA – drive to more agile, adaptable, responsive, resilient, and profitable enterprises. It also discusses how to determine SOA’s business value including SOA ROI calculation.
- “Organization” discusses technology and organizational impact of SOA adoption and implementation
- “Governance” addresses SOA governance, including its role in achieving business results with SOA adoption.
- “Methods” covers service identification and definitions
- “Applications” covers relationships between applications and services and the impact that SOA has on application development
- “Architecture” discusses architecture from various views (for example, application architecture, integration architecture, and enterprise architecture) and discusses the impact of these various views and their interrelationships with SOA.
- “Information” covers data architecture and management, including data services, canonical data models, etc. in SOA.
- “Infrastructure” addresses middleware support for SOA, including enterprise service bus, registries, service monitoring and management, etc.
- “Future” discusses where SOA is going and new SOA trends, including context-aware services.
Pearson/Prentice Hall Professional provided Infoq readers with an excerpt from chapter five of the book, focusing on service identification*. InfoQ had a chance to interview Kerrie and Ali.
InfoQ: When defining SOA as an architectural style you are effectively showing the famous find/bind triangle and coming to the conclusion that it does not buy you anything outside IT. A different definition of the SOA style:
“SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions.”
This gets to the most important SOA features like IT/business alignment, service composition, etc. Would you consider the latter as a better definition of SOA architectural style?
Kerrie and Ali : Perhaps we could have phrased the question, “Is SOA an Architectural Pattern” rather than “Is SOA an Architectural Style”, in Chapter 1, SOA Basics. Yes, our illustration aligns and matches the “famous find/bind triangle” which can be seen in many articles such as this article from Oracle, Figure 1: but with the big caveat in our answer being that SOA is more than an architectural style. Our book makes the point that SOA as we define and discuss is a new concept, a departure from how it was defined in the late 1990s, and not limited to an architectural style or architectural pattern.
The article is excellent and I highly encourage its review. The article suggests the definition of an architectural style be expanded as author Robert Hubert suggests in his book, Convergent architecture: Building model-driven J2EE systems with UML to cover the entire software life cycle. Expanding the definition of an architectural style to include the entire software life cycle is problematic as distinctions become blurred between types of patterns, architectural boundaries, to name a few concerns. Wikipedia provides a definition of what is an architectural pattern and in our book answer we did not make the distinction between an architectural style and an architecture pattern. However, our answer aligns with the definition of an architectural pattern. Given an expanded definition of an architectural style, a resounding yes, the said article provides a better definition of SOA as an architecture style.
InfoQ: In the book you write “The implementation of SOA technologies without a deployment of one or more services could also be defined as an SOA implementation.” Are you saying that usage of web services or ESB constitutes an SOA project?
Kerrie and Ali : Yes, in Chapter 1, question 5, we address the question of “What Makes a Project an SOA Implementation” and make the point that deploying or implementing Web services or an Enterprise Service Bus (ESB) constitutes an SOA project. We go on to state that there are a wide range of SOA adoptions or project types, each of which accrues different benefits. Our message is that instead of debating whether the project was an SOA implementation, the better question is to understand what benefits accrue from the SOA implementation. A project that solely adopts one or more Web services or merely implements ESB patterns or ESB product technologies will accrue very few if any SOA benefits. The OSIMM standard provides an opportunity to see a wide range of SOA maturities and at the same time understand the different benefits that accrue with each.
Organizations can start at a lower level of maturity in regards to services where the organization implements a few web services. This type of project may help to improve a business process by accelerating 3rd party interactions. This would constitute a SOA project although only a few or one Web service was realized. Similarly, an organization may adopt an ESB pattern or ESB technologies where service(s) and/or the ESB pattern is realized to facilitate integration and this would also constitute a SOA project.
InfoQ: As you write in your book, “Measuring return for IT solutions is notoriously difficult” and measuring ROI for SOA is even more complex. Can you point at the practical approach for SOA ROI calculation, which goes beyond common phrases?
Kerrie and Ali : Some organizations must do business case justification and/or ROI to proceed. We continue to recommend that projects and teams do business case justification or business ROI as usual rather than focus on SOA ROI. However, we recognize such an answer is inadequate for some. Practically speaking some organizations need to demonstrate using traditional ROI approaches, the value and return on making an investment in new technology, skill building or even an extended schedule.
Several organizations and analyst firms have made public their calculation methods or suggestions and we believe this represents a good approach and answer. For example, Tibco provides a free –to- use SOA ROI calculator, see this link . IBM provides a business value analyzer tool, see this link.
There are some excellent published articles which describe various ROI calculation algorithms, see:
- The ROI of Your SOA
- The Oracle website and a search of “ROI of SOA through reuse” returns a PDF with ROI calculations
- Service-oriented architecture: Measuring SOA's ROI in the new economic environment provides a download of a PDF from IBM’s Institute of Business Value (IBV) which provides SOA ROI calculations
InfoQ: In your book one of the questions is “Can SOA Be Applied to Business Architecture or Should It Be Used Solely for IT?” Should the real question be phrased as, “Is it possible to build SOA implementation without Business Architecture?” If the underlying business architecture is not defined, how can we achieve Business/IT alignment?
Kerrie and Ali : We can use SOA as a means of driving the definition of Business Architecture through such constructs as the Goal-Service Model. So, SOA can be applied to elaborate business and IT architectures. However, your question is excellent and a different question than what we asked in Chapter 2, Question 14. It is certainty worthy of an answer.
Yes it’s possible to build SOA implementations without a fully elaborated Business Architecture but the more mature an organization is in its definition and use of Business Architecture, the more likely business alignment and business benefits will accrue with SOA adoptions that leverage and operate under such Business Architectures. If we look at business architecture as business processes and business goals, then their absence severely compromises business and IT alignment. So it’s unlikely organizations will achieve their business intent or business design without the underlying business architecture. However, this does not mean that organizations must have an enterprise-wide business architecture or that the business architecture must be fully elaborated in all aspects.
InfoQ: In your book you are discussing different types of services, including business services, IT services, information services, or utility services. This basically means that anything that is distributed is a service and SOA is effectively a distributed computing paradigm. Should we start equating services with only business services and treat everything else as components (potentially distributed)?
Kerrie and Ali : SOA is more than a distributed computing paradigm although it clearly supports such a paradigm. In Chapter 3, Question 24 ,we discuss the value of classifying services. However, reading the answer does not infer that everything that is distributed is a service. In fact, we can and do distribute components that are not services nor are they invoked or accessed using services. Business services are a classification and there should be a purpose in classifying services as business services which is the primary point in our answer. So there may be value in expanding the classification of services beyond business services as seen in the examples in the answer to Question 24. No, we should not treat everything as either business services or potentially distributed components. In Chapter 1, SOA Basics, Question 3, we describe the attributes of a service. In Question 24 we go further and describe the value in classifying services. In Chapter 7, Architecture, Question 65, we answer the question of what is the difference between interfaces and contracts, which provides an answer for what is different between services and components. Both are needed but they are different. In Chapter 5, Methods, Question 40, we describe why the use of services in addition to components is necessary for structuring the application.
InfoQ: While discussing changes in system development from SOA, you have a great discussion on how an existing set of services helps build better, more reliable implementations. But what will happen in the beginning, when there are no services yet?
Kerrie and Ali : We have to start a journey in order to reach a destination. So if we look at making an application more agile and more reliable over time, we can start making this a reality when we begin the construction of the application. If we look at an application portfolio this will occur incrementally and as needed over time. So in the beginning we have our existing, as-is state with no services; it is only when we launch new projects, or when transformation initiates, that the current state evolves to the direction and vision. Organizations that change their system development methods now, versus later, will get there faster.
InfoQ: A great discussion on service identification seems to have a slight contradiction. On one hand you are talking about defining and implementing services within a given project, but then you are talking about domain decomposition and goal-based modeling and asset analysis, each of which presumes an enterprise-wide approach. How do these two coexist?
Kerrie and Ali : In Chapter 5, Methods, Question 41, we answer the question of how should services be identified. Domain decomposition, goal service modeling and asset analysis can be applied at a project level, enterprise level or hybrid. For example, on a project, goal service modeling can be used to ascertain the strategic imperatives of the business for launching a project as well as the expected business outcomes and corresponding key performance indicators for measuring whether the outcomes were realized. Domain decomposition can be used to understand and document the to-be business processes, providing business use cases for the project; and asset analysis can be used to determine if existing services or components are available in the application portfolio or enterprise for reuse by this project.
The three complementary techniques can be used in a single project, or for enterprise-wide transformation, or in a hybrid where enterprise goals are sought under a program that has multiple projects. The service identification approach benefits from casting a net that has a larger scope such as the enterprise, but it can also operate under a more narrow domain that is confined to a project.
InfoQ: Throughout the book you talk about the fact that SOA does not change applications-centric IT mentality, which seems to directly contradict with the way services should be identified and implemented. On one hand services themselves are mini applications; on another hand, the whole purpose of SOA was to break applications silos – islands of data and automation. It seems like services for applications will leverage only SOA technologies, not SOA architectural style, while services for enterprise seem to make application obsolete. Can you elaborate on this?
Kerrie and Ali : SOA thinking and adoption can change application- centric IT mentality by focusing on services as business assets in addition to applications as business assets. SOA has a broader focus than breaking silos, including eliminating the negative aspects of silos such as the inability to access function embedded in applications or the ability to rapidly reconfigure functions locked in applications. We encourage the use of services for both requirements management and for structuring applications such that services become first class business assets. Services don’t exist for applications; services provide a way to extend the life of applications and to foster and accelerate the ability to reflect business intent in IT systems.
Adoption of SOA and services will not make applications obsolete as services will most likely be packaged into applications and not all applications will adopt SOA. Services- whether lines of business, departments or at the enterprise level- will at certain adoption stages or maturity levels both adopt and leverage the SOA architectural styles and technologies. Some services will be used at the enterprise levels while others may be limited to particular business units. Such adoption does not mean the services used only in a business unit cannot easily be expanded to the enterprise level.
InfoQ: When comparing SOA with DCE and CORBA, you seem to really be comparing Web Services with earlier approaches to distributed computing? Does it mean that you are equating SOA with technologies that are used for its implementation? Is a set of technologies really crucial for defining SOA?
Kerrie and Ali : In Chapter 7 Architecture, Question 62, we discuss the differences between SOA and earlier approaches such as DCE and CORBA. We emphasize five differences: standards, extensible markup language, means of accessing databases, contracts versus interfaces and services as business assets, as distinct differences between SOA and prior approaches such as CORBA and DCE. At the same time when we discussed standards, the bulk of the standards we illustrated are focused on Web services that may have diluted the message that there are five distinct differences. No, SOA is definitely not equal to the sum of the technologies used to implement or realize SOA. That is, the set of technologies is not crucial for defining SOA as discussed in Chapter 1, SOA Basics, and Question 1, “What is SOA.”
InfoQ: Another interesting comparison point that you have in the book is REST vs. SOAP. Should in reality this be SOA vs. ROA? You seem to come to the conclusion that resource is equivalent to service. Can you elaborate on this one?
Kerrie and Ali : We purposely discussed REST versus SOAP as REST is often associated with Resource Oriented Architecture (ROA) and SOAP is often associated with SOA, but the two are not mutually exclusive. That is, it’s possible to adopt SOA with REST implementation. Applications are a combination of things that might be resources and services or events. REST appears to be the primary implementation of ROA, so is ROA, Resource Oriented Architecture or Restful Oriented Architecture? SOA and REST are problematic to compare as they are different levels of abstraction, so if ROA is nothing more than REST, it also is problematic in comparing. So answering the question of SOA versus ROA depends on how we define ROA and how we define SOA. ROA was coined by a single person and we can trace its history, but since SOA has a more fuzzy history, its multiple definitions abound.
We are not equating a resource in ROA as services. In fact nowhere did we address the notion of ROA or ROA resources. SOA most often addresses payloads where ROA usually is addressing URLs, requesting addressing. So with ROA there is a unique resource per address where with SOA there is an endpoint address per service. ROA is largely for read-only data. But applications can adopt both approaches and depending on how you define ROA and SOA, ROA could easily be seen as a subset of SOA especially when its only implementation is REST.
InfoQ: Comparison between SOA and SOI in the book is slightly confusing. Is this as simple as saying that although the two can share the same technology stack, SOI exposes directly the existing application’s functionality as a service interface, while SOA exposes directly business-aligned interfaces and hides existing applications’ functionality?
Kerrie and Ali : Our answer on the differences between EAI, SOA and SOI was meant to compare and contrast. Chapter 7, Architecture, Question 68, addressed the question of what is SOI. Like with SOA, SOI has different and sometimes conflicting definitions. We simply defined SOI as service oriented integration where SOA and/or Web services are used to realize the integration. We also stated that SOI could be used to describe integration patterns that leverage services (Web services or otherwise) and/or SOA technologies. We see SOI as a subset of SOA and not separate. We don’t see utility in trying to distinguish SOI from SOA. Yes, SOA and SOI can share the same technology stack. Yes, SOI exposes existing application functionality as a service interface. However, SOI could also be described or defined as adoption of an ESB which promotes accessing, routing or transformation for business aligned services. So again it all depends on what’s in a name. Do we define SOI in terms of patterns? Do we expand the definition to the realization of those patterns? In either case SOI becomes more than simply exposing existing applications’ functionality as a service interface.
InfoQ: When defining information services you seem to imply that those are the ones providing CRUD interface to the data. This seems to contradict the CRUDy anti pattern for SOA. How can you bring these two together?
Kerrie and Ali : The article on CRUD as an anti-pattern focuses on designing SOA services with .NET. When reading the symptoms and consequences of the CRUDY anti-pattern, the author by default equates SOA service with a Web service without defining either. The author goes on to describe how to mitigate the risk and issues but the solution still uses CRUD. So I don’t think this is a good example of a CRUD anti-pattern but more an example of an anti-pattern for implementing CRUD with a .NET solution.
In Chapter 8, Information, Question 74, we describe how information services can be classified. One of those classifications can be a data service that is largely implementations of CRUD. Of course if it is a service, it must adhere to the attributes of a service that we describe in Chapter 1, SOA Basics, Question 3. This is true regardless of how we classify the service. In this book we don’t focus on Web services but SOA services and we define both and their differences (see Chapter 1, Question 4). So by understanding and implementing a SOA service as described in Chapter 1, one avoids the consequences defined in the referenced article. In addition, in Chapter 8, Information, Question 77, we describe scenarios where it might make sense to create a data services that is CRUDy. We avoid the negative consequences described in the CRUDy anti-pattern of not using an XML schema as all SOA services have a WSDL or equivalent, and a contract versus an interface.
InfoQ: In your book you seem to imply that registry and repository are the same thing, although in reality they solve separate sets of problems. Do you consider implementing them as a single entity a best SOA practice?
Kerrie and Ali : In Chapter 9, Infrastructure, Question 83, we identify and define the building blocks of an SOA infrastructure which includes a registry. We specifically don't identify a repository because repositories are used for a wide range of concerns beyond SOA and we don't see a repository as a unique building block of SOA; although repositories may be required to make the SOA infrastructure operational just like integrated development environments (IDEs) may be necessary to realize services. So registry and repositories are not the same thing, and we agree they solve separate sets of problems.
In answering Question 87, as to how the ESB and registry relate, we provided an illustration showing the life cycle of using a registry where a repository would also be used to facilitate discovery of service endpoints. No, we don’t consider the implementation of registries and repositories as a single entity as a best practice, nor do we frown on it as a practice as this is an architectural decision that enterprise and project needs must determine. Life cycles for governance, security or registries, for example, will need to house metadata to manage the life cycle and a repository is just such a choice. Vendor technologies which have a registry and repository as a single entity can offer advantages in optimizing governance and management.
* This excerpt is from the book "100 SOA Questions: Asked and Answered" by Kerrie Holley and Dr. Ali Arsanjani, published Nov. 2010 by Pearson/Prentice Hall Professional, ISBN 0137080204, Copright 2011 Pearson Education,Inc. For more information, please visit this link.
Evolving Culture and Values. Understanding the Tradeoffs. Growth through Failure. The Importance of Leadership and Open Communication.
Pedram Keyani Mar 11, 2014
Summly: An Award Winning Mobile App's Journey to the Cloud with Five-9s Availability on a Shoestring Budget
Eugene Ciurana Mar 11, 2014
Christophe Achouiantz Mar 11, 2014