Missing-link between Business Architecture and Service Oriented Architecture (SOA)!!!

Before we embark on the effort of establishing a link between Business Architecture and Service Oriented Architecture (SOA) here is an attempt at creating a loose working definition for each.

SOA is an architectural paradigm that allows one to model, build and measure reusable business components that can be flexibly assembled to offer a business service.

Business Architecture is an architecture style that structures the accountability over the most important business activities (for instance production, distribution, marketing, etc।) and/or the economic activities (for instance manufacturing, assembly, transport, wholesale, etc.) into domains.

To begin with here are a few key SOA principals that all apply to the realm of Business Architecture. Principals of loose coupling, abstraction, reuse and interoperability (of both messages and the operations) all of which facilitate composition of more course grained business services.

So what does a Business Architecture effort entail and how is SOA relevant to the discipline of Business Architecture? Business Architecture should focus on broad reusable business components that can be turned into or wrapped into reusable service components and/or business services. The term reuse has received a bad wrap but when looked at from the lens of being able to offer enterprise wide consistency and cross-business area interoperability one begins to realize that this very attribute of “reuse” has the potential to deliver speed to market and cost reduction both of which are touted to be powerful selling points for SOA. From this perspective Business Architecture can be seen as a precursor to SOA.

Business Architecture should be designed to help align the right business operating model (low cost services provider or innovation oriented service provider or niche services provider or a service provider that offers low cost processing to meet regulatory compliance needs etc.) with the value chains and the component business processes. Following this effort one would need to study how to alter business activities and those value chains that are directly impacted by the changing business needs (which are external influences to the operating environment). Without undertaking this study it is not possible to identify "appropriate" business strategies that fit the underlying operating model chosen by the business. This effort has to precede SOA based service definition work as this thought process enables rationalization of the current state “service worthy assets” and helps in the identification of business service interface for these assets.

Given the above description of the discipline of Business Architecture one would logically arrive at the conclusion that for the concept of Business Architecture to truly take root in any organization it is imperative that business strategy be considered the "driver" of the Business Architecture effort(s). In addition one will notice that package solutions and infrastructure / frameworks can only be treated as an enabler for the identification of business optimization opportunities (within the value chains and their component business processes) but are definitely not the drivers of Business Architecture work or SOA work. There are some other considerations as well such as the role of a Business Architect, the executive sponsorship for Business Architecture etc.

The role of a Business Architect is a critical aspect of Business Architecture to succeed. Since the “business aspect” of Business Architecture is important finding someone with the right type of business knowledge to fulfill the role of Business Architect would be a must have. Also, having someone with the ability to apply the philosophy of architectural abstractions to the business domain is important. Fortunately for us architects this is great news as some of the lessons learnt from SOA can now be easily translated to the realm of Business Architecture long as we have the right level of business expertise as well.

Having said that, Business Architects will need to be cognizant of the fact that they have to strike a fine balance between their technical and business skills. In addition, people in this role have to be careful to not engage in prematurely promoting the principal of business process abstraction (a core architectural principle), without first establishing the right foundation for introduction of this concept. The reason is that the Lines of Business owners possess a very keen sense of pride in being “unique” and abstractions often lead to the erosion of or removal of “unique” customizations where ever these interfere with the larger scale intent of the business process/ value chain.

Business Architects need to have enough business savvy to engage with their business partners on an equal footing. They have to first express the nuances of the various problem domains before they start the process of abstracting and drawing parallels across the business processes owned by the multiple Lines of Business. Even during this phase Business Architects have to be able to explain these abstractions in business syntax and show how the competitive advantage “uniqueness” can still be incorporated without loosing operational efficiency. To be able to articulate the concept in business lingo and to tie this to financial impact by walking through the underlying analysis is the only way to get business buy-in given that these are the metrics up on which Lines of Business owners are measured. If not done by garnering the right partnerships the resultant enterprise-wide operational efficiency or competitive advantage benefits would never be realized.

If one cannot find this Business Architect, a cross-functional team with complimentary skills may be able to pull this off. In order for such a cross-functional team to be able to execute effectively on any large scale Business Architectural/ SOA effort it must have the support of a prominent executive sponsor. The executive sponsor has to be able to articulate business strategies, and influence key representatives of the Lines of Business to collaborate with a group such as the Enterprise Architecture Group. Executive support of such a team enables it to effectively analyze and abstract broad Business Architectural constructs and can help define and drive business solutions to implement business strategies that align with the chosen operating model of the organization.

An oft asked question on executive sponsorship is whether it is the CIO or the CEO and the influence that technology has on such an effort. This depends on the type of organization, the charisma of the CIO and the business acumen of the CIO vs. the technical acumen of the CEO. Also, key to this decision is whether technology is a business driver for this organization or is at least a key component for driving the operating margins.

Finally, for Business Architecture, the related SOA work and the business solutions to be considered part of a sustainable model this body of work has to deliver tangible and measurable benefits. The measures and the value proposition will have to be agreed upon at the outset of embarking on this path/ journey. In addition this multi-step journey has to be associated with a set of well-understood and well-published multi-year target business deliverables.

For some additional information on Business Architecture please review content on related blogs:
Business Architecture – Process Architecture and Information Architecture!
Key Best Practices - What is Service Orientation?

Thanks in advance for your feedback.
Surekha -

Key Best Practices - REST Assured????

The purpose of the blog is to find out if there is a place for REST in the realm of “Business Services”.

First of my definition for REST – it is a "Get", "Put", "Post", "Delete" operations performed on "Resources" that are identified as URIs being transmitted over HTTP(S) as REST.

REST by nature has a very simple service operation set with the complexity all embedded in the Resource URI. The operations that REST allows are NOT business user-friendly and hence do not really belong on the Service Repository that an end user is referencing to discover business services. To accommodate complex business behavior and to compensate for the finite list of RESTful operations the resource identifiers have to be fairly complex.

SOA on the other hand, allows fairly diverse interface definition that resembles as closely to the business syntax as it can get. The canonical model that is shared is standardized and is not as diverse as are the resource URIs of the REST architecture. The canonical models for the most part are XML.

Another key difference lies in the protocol and messaging support for REST. REST is limited to only HTTP/ HTTPS which by nature is stateless and has no standardized protocol level interception model for the more enterprise category behavior such as guaranteed delivery of messages and asynchronous messaging semantics. SOAP and the standardized metadata associated with SOAP envelope on the other hand can be interpreted by the Web Services SOAP stack to enable behaviors such as Reliable Messaging, Transaction Management, Addressing, and Notification with a level of interoperability across-vendor platforms.

Having said that, it is possible to find a home for RESTful architecture and to leverage one of its strong points in terms of a simplified and standardized interface. REST may be a good architecture model or construct to follow in the service implementation layer or at the service adapter layer. This helps to keep the service implementation the same across any type of service interface definition. In the event there is a need for additional transactional integrity then these behaviors could be taken care of in the service facade or in the service mediation layer while keeping the actual implementation in the simplified RESTful architectural format.

If we are looking at SOA service operation being exposed to the world and using a RESTful service implementation layer then we would need to deal with translating canonical models and parameters of SOA style service into URIs. This translation behavior includes extracting the request parameters from the Request canonical model and transforming these to verbs and values in the format of a query string i.e. a URI.

One option is to have the specific URIs needed by the service implementation layer to be translated to the input URIs as specified by the RESTful service implementation layer. Here the service interface layer or the service mediation layer performs the translation of the input parameter into the specific URI and initiates the invocation of the appropriate service implementation layer.

The other option is to have the service interface layer or the service mediation layer translate the input into a generic URI for calling the RESTful implementation layer which in turn does the mapping internally to the required operational version of the URI. This improves the durability of the service interface layer or the service mediation layer. In addition, it provides a mechanism for doing internal operation overloading and polymorphism.

Regardless of which option is chosen, I would think that embedding RESTful services in the implementation layer would be a good option while not exposing painfully abstract behavior to the business user who is used to seeing more of English like business syntax.

Here is a link to another blog of mine on the topic in the context of Service Orientation!

Even though I agree that there is a place for REST as it may simplify (by providing a finite set of operations) there are infrastructural capabilities that do not exist with the REST and without these the business agility piece is going to be hard to deliver. Here are some additional thoughts on the topic that an enterprise architect may have to resolve prior to embarking on a RESTful implementation.

1. Identify which layer deals with the interpretation of the get(Resource) call? Is it the service provider (SP) interface or is it the service implmentation layer?
2. Would the SP be dealing with versioning of the Resource thereby creating a grand facade that does internal resource mapping via a URL redirect style substitution? This would be one way of protecting the service consumer (SC) and to accomplish backward compatibility.
3. Identify how the SC gets the handle or URL to the "right" resource? How does it "know" what to expect from the Resource and how does it "know" to express its' semantic expectations for the SP Resource that is being called upon? Does it do a "Get(SearchByCriteriaResource)" call with semantics embedded in the Request Resource?
4. Is the get(RightResource) another call and somehow the metadata held in the response Resource is expected to have the "right metadata" for each of the provider Resources (that meet the SC search criteria) in order to help the SC choose the right SP? If this is the case, then following this invocation would be a secondary SC to SP interaction to fetch the chosen SP Resource.
5. Identify if there would be a standardized URI with search criteria specification. This might be good to define up-front to enable the support of JINI-like or SaaS like interactions?
6. Identify and define how one would deal with asynchronous interactions? Would it be via the use of " ack/ no-ack post notifications" and "post response Resource" calls? How would this be to handled? The SC would have to provide a pre-set "call back" Resource identifier to which the SP would have to reply back to?
7. Would existing messaging infrastructures still work as most of them have proprietary protocols or else they support JMS/ RMI?
8. Identify a URI for brokering of the two-part synchronous post HTTP call to. This would be for enabling the pseudo-asynchronous interaction semantics. Is the centralized broker URI all that is needed to broker the two part synch call for faking the Asynch interaction semantics especially if the architecture does not have to deal with message delivery guarantee? I assume "post" might have void return type communication model to enable releasing of calling address space resources?
9. Would one have to leverage any "Registry" or ESB like middleware or "service grid" like infrastructures? If so, how does would resource proxying work? Would the proxy Resources’ "forward" their calls to the right Resource?
10. Would this mean that the middleware and mediation layer products need to know how to deal with this type of an interaction semantic where the "Registries", ESB, "service grids/ service marketplaces" are all metadata-driven Resource proxies with built-in support for REST - as opposed to service proxies as would be the case in SOA style architectural models.

Thanks in advance for your feedback.

surekha -

Business Architecture (Business Design) - some interesting anecdotes

This is in follow-up to Ashok's previous blog on Business Architecture. After publishing the EA 2010 domain model (web cast) the SOA Consortium EA 2010 working group has primarily focused it efforts on explaining (note: not defining) what Business Architecture means to us practitioners. One quick observations from these conversations was that most practitioners where interchangeably using the term Business Design and Business Architecture - basically Business Architecture effort is to come up with Business Design that can adapt to change (more to follow as and when the SOA Consortium get ready to publish this out).

In my opinion - even though the term Business Architecture may not have existed, some large enterprises as well as governments have been defining long-term strategic plans (Business Design) that adapts to change.

Lets take the example of Nokia - if you review their history one would be surprised to learn that Nokia was established in 1865 as a wood-pulp mill. Since then Nokia has been involved in many sectors, producing at one time or another paper products, bicycle and car tires, footwear (including Wellington boots), personal computers, communications cables, televisions, electricity capacitors, aluminium, etc. (Source: Wikipedia)

How did they go through this transformation? I did have an opportunity to partner very closely with Nokia during the dot com days and according to Nokia GAM, Nokia typically establishes a five year plan (Business Design) and executes to it. For example - once they determined that the PC business is going to be a commodity - they sold it and moved on to a new market segment. Looks like they adopted the Business Architecture approach established by the Soviet Union. History demonstrates that it did not work for the Soviet Union, but did work for Nokia. Maybe it had to do more with the market dynamics that the five year plan itself. The economy of India is also based on five year planning (the Soviet Influence) and the entire bureaucracy is measured against achieving this (and as usual the Politicians do interfere :) ).

Yes! it is very useful and great to publish the business design but not necessary for the market place. For example, Oracle which was known as a technology company is now viewed (by the industry) as an acquirer. IBM transformed itself into a Services Company but they still do have hardware and software. In this case the Business Design is essential to help define and explain the role of the hardware and software plays in it's services offerings. If not clearly defined (which includes the monetization aspect) one could land up as a niche players like Sybase and Sun.

These days there are lot of discussions going in various enterprises, forums, consortiums, enterprises and government organizations on topics such as:

• what is business architecture?
• where should it belong? (part of the EA team or business)
• what is the right place for EA? (shouldn't the CEO and the Board be involved in EA?)
• ...etc.

In my opinion - there is no right or wrong answer. Do what you thing is right (or what you can achieve) within your organization. Like my take on our SOA Adoption within BEA-IT, we went about adopting the right enterprise architecture approach which happened to be Services-Oriented Architecture. We did not set out to adopt SOA. As an early adopter of SOA - we saw the benefits which transformed us into it's early advocates.

Hope this was interesting and do drop me line to discuss this further, if interested.

- Yogish Pai

Enterprise Service Bus vs. Service Component Architecture

My attempt is to present a simplistic view of my take on the purpose of an ESB (enterprise service bus) and SCA (service component architecture). This entry is in response to my esteemed colleague's commentary on "A decision makers concern about ESB " where in the two concepts of ESB and SCA were being compared. I must add that I am in complete agreement with Yogish on the fact that ESB vendors are adding to the confusion of what is and what is not part of the "core feature set" of an ESB.

My own opinion (misplaced it might be!!) is that ESB vendors tend to bundle a lot of "service creation"utilities and "adaptors" into the base ESB stack, in an attempt to achieve "product differentiation". This very act causes ESBs to become both ridden with "service behavior" which may also lead to "slow performance" of the ESB based mediation. The reason being that it becomes very difficult to performance tune an architecture component that is doing multiple things - it breaks the rule of "high cohesion" in doing "service mediation" and "service behavior execution"!!! The former is a high through-put pass through activity while the later could have fairly intense computation business logic or data processing logic.

Now back to the ESB vs. SCA topic.

ESB - promotes the abstraction of the service provider from the service consumer. Here it is assumed that the goal of exposing the service provider interface is to enable the reuse of the service provider business behavior. ESB' core theme being service mediation.

SCA - promotes the abstraction of wiring in of the external resource dependancies and external transport protocol bindings from that of the core and reusable business behavior of the service. Here the assumption is that the component parts of service provider can be re-assembled in various combinations to assemble services that are invoked from multiple consumer contexts. SCA' core theme being service assembly.

ESB enables service interaction/ mediation from multiple service consumer contexts while SCA enables service provider component parts to be assemble for "servicing" multiple service consumer contexts.

In both cases, the attempt is to decouple service usage from reusable service behavior.

Your comments on this topic are invaluable.
surekha -

SOA Practitioners Opinion on Business Architecture

As Enterprises are starting to adopt Services-Oriented Architecture, they are currently in the process of transforming both their Business and IT organizations. In this context there has been a discussion on the topic of Business Architecture with a basic consensus that Business architecture is the link between business and technology (or IT) but there isn’t any clear definition of the roles and responsibilities of this position. Nor is there clear descriptions of the practical aspects of what exactly are the Business Architect’s activities and how should enterprises get started with this function. The objective of this paper to help clarify these points from a practitioner’s point of view as well as help organization kick-start the Business Architecture function.


Table of Contents:

Industry Context
Enterprise Value Discipline
How Organizations Learn

Introduction to Business Architecture
Business Architecture Defined
Business Architecture Responsibilities

Getting Started with Business Architecture
Adopting Services-Oriented Architecture
Business Driven SOA Planning Framework
Business Architecture Governance
Enterprise Architecture Governance
Enterprise Architecture Organization Structure

Proven Approach to Business Architecture Blueprinting
Developing the Business Architecture Blueprint

Conclusion

SOA Consortium – Ground Floor SOA – Recap for 07

The most significant progress we on the SOA Consortium Working Group of "Executing Business Driven SOA" have made in the past year was in the definition of the SOA Planning Framework. Efforts undertaken as part of the SOA Planning Framework track will include classification and logical grouping of the collective body of work done thus far by the Strategy 2 working group; thereby allowing us to deliver a single document that can be used as a reference by anyone who embarks on the path to SOA-enable their enterprise. This includes work done under the headings of “SOA Readiness Assessment”, “SOA Opportunity Identification” and “High Level People, Process and Tools” matrix. All of this material will find a home in the various sub-components of the SOA Planning Framework. Once completed the SOA Planning Framework will be one of the most comprehensive guidelines for those looking to implement SOA.

The other key benefit of the SOA Planning Framework deliverable is that it allows an enterprise to start on one or more of these components without forcing it into having to define all components prior to getting started on the SOA Roadmap. This is where the SOA Planning Framework differs from that of a rigid SOA methodology - in that it is a loosely-woven collection of SOA enabling constructs.


Again, I would like to thank you of the members of Strategy 2 for your participation and invaluable input. I look forward to a very productive upcoming year.

surekha -

Key Learnings - Profile of a Business Service

My experience has led to the creation of the following service based postulates. These were applied by me on major retail SOA projects.

You can find these and other laws posted on the SOA Blueprint site. http://www.soablueprint.com/soa_laws

1. A service should expose a single business function or business process in it’s' entirety
2. A service should not make assumptions of the validity of the request and should validate the request for accuracy including checking that the requestor is authorized properly prior to honoring the call
3. A service should delegate to the right enterprise resources to completethe business function
4. A service should be responsible for notifying and dispatching the right requests/ information to all related services and/or applications on behalf of the requestor
5. A service should be responsible for any call chaining, sequencing and aggregating of the requests and the intermediate responses in order to completely process the consumer’s original call
6. A service should provide business information as a canonical documentthat is consumable by both human actors and system actors
7. A service should return a response that has the business context built in along with the response to the question asked by the requestor
8. A service should rely on enterprise worthy metadata information including the application of any algorithms, enterprise-wide business rules and strategies in order to process the requestors' call

Your feedback is appreciated.

- surekha -