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 -

Business Architecture – Process Architecture and Information Architecture!

First the problem statement - Typically the Line of Business (LoB) owned business processes and IT owned data/ information aspects. This would then help explain why these two key aspects were never in synch. The industry is now realizing the need for alignment between the process and the informational aspects and has created a new discipline of “Business Architecture” to encompass business process and business information.

Here the idea would be to leverage the business information flow in an optimal manner to drive business process definition, business process engineering and business process optimizations as opposed to shoe-horning this crucial business information into the business process. It must be noted that business information can take forms such as rules to transform business data, business decisions made in the context of an exception in the process, regulatory influences on a process or short-circuiting rules that enable a process to either be aborted without a detrimental effect on the process or rules for enabling a process to be completed quickly in “special business situations”. It is the access to this contextual business information that makes business process automation possible without losing the knowledge base of the subject matter experts.

A key goal of Business Architecture is to bring about the efficiencies of business process by access the right information. As was mentioned earlier, business architecture allows sharing of business information that is an enterprise asset in the context of a business process that is a LoB asset. Business architecture also helps highlight lost opportunities by drawing up scenarios where lack of business information availability (due to "not invented here complex" or lack of proper stewardship) prevents business process efficiencies from being realized. In addition, business process without the decision influencing contextual information still leaves the LoB user to make one off decisions that may be either based on invalid data or insufficient data and leads to process execution inconsistencies.

Furthermore, in an exceedingly inter-related enterprise or even extended enterprise sub-optimal decisions made in any business process leads contradictions in the rest of the enterprise. From an upstream process perspective, these lead to business strategies being interpreted erroneously. From a downstream perspective the business events being emitted by the siloed business process may have insufficient or improper information for execution leading to more exceptions in the downstream steps of the process. This may , slow down the entire business process chain having a negative impact on the business.

Another key goal of Business Architecture is to insure that the business information captured as part of Business Process Optimization efforts is consistent in its’ reporting. Here business process decisions made prior to the process reengineering efforts and after have to be captured consistently and accurately. This base line allows the study of the process efficiencies to be quantified. If the business information that is emitted in the form of business process based events is not being made available beyond the LoB process boundary then again sub-optimal process execution in the downstream steps could overturn the effects of any optimization work.

Information has to be captured consistently, emitted in a timely fashion and finally the events have be interpreted accurately to insure that the business strategy and the optimizations that are being envisioned by the business in implementing the value chain activities are in fact resulting in competitive advantage. This knowledge enables further process improvements and makes it easy to deal with business process adjustments especially when enterprise is faced with making a dramatic shift to deal with changing market conditions or regulatory conditions.

Finally, business process management, business process optimization and business activity monitoring need access to a well thought out MDM philosophy and strategic analytical marts that can be accessed via informational business services. These type of information access services can combine real time operational BI, real time business events and analytical sources to "close the informational loop"!!! Please see my whitepaper on this topic as well - Closing the Loop: Using SOA to Automate Human Interaction!!

As always thank you for your feedback.
surekha -

Explaining the terms "Services-Oriented Architecture"

Recently there has been some interesting discussions on multiple on-line groups on defining Services-Oriented Architecture. My observations has been that a majority of the participants on the on-line forums refer to SOA as an Architecture Style. I would agree with this, however I would not mention this to the non-IT staff. What would they care or know about (Enterprise) Architecture Styles? and does it make any sense for us to explain this to them? We might be better off learning more about their needs instead.

Wikipedia definition starts with "SOA is a software architecture...." and because of this, I would not agree with it. Maybe one of these days I shall get enough courage to change it on Wikipedia :) .

I just read Surekha's blog on Key Best Practices: What is Serivces-Orientation? and am in complete agreement with her that

There is no place for the use of architecture terms, technological jargon or even as much as a mention of the web services or the WS-* stack in this definition!!

I would still define SOA as described in the SOA Practitioners Guide Part 1: Why Services-Oriented Architecture? . The SOA Practitioners defined it as follows:

SOA is a business operations strategy for leveraging information to meet the organization’s objectives, such as increasing overall revenue, boosting customer satisfaction, improving product quality, and enhancing operational agility.

Following are the reasons why this still makes sense to me:

First: Business is responsible for their own strategy (some interesting anecdotes) and yes! IT should (note: not MUST - IMO) have a seat at the table to help influence the strategy. Once the business stategy is established it is the responsibility of Business Operations to execute on the strategy. This is where IT comes in - parnering closely with Business Operations in developing the Business Architecture. People from the IT Organizations generally interact with Business Operations on a day-to-day basis. The IT Leadership does interact with the business executives but more on a periodic basis. It is for this reason I prefer the term SOA is a Business Operations strategy for leveraging information.

Next: I like all strategies to be actionable, i.e. a roadmap for achieving specific desired goals. For example, the primary goal for SalesForce.com (Disclaimer: I know as much about SalesFoce as most of the readers of this blog) is to most probably to become the primary platform for ALL SaaS solutions in the market. In this case, the business operations folks (sales, services, marketing, finance and IT) have most probably defined approaches for meeting this objective (which could be in form of marketing campaigns, events, sales incentives, partner programs, etc.). In order to execute this strategy they will require services from their own internal IT (yes! they do have an IT Organization) to provide them the capability to execute and monitor the progress (...leveraging information to meet their objectives).

Finally: I agree Todd's and Rob's thoughts about the term "The Business" - my observation is that this is not limited to IT Organizations. This is true for all organizations where I have heard sales executives refer to the "Those Marketing Operations folks" and so on. The only company where I had seen systematic approach by executives to rediret the entire company to consider themselves as a single team was at The Coca-Cola Company (or at least that was my observation in the early 90's - when I was in their IT organization). So even though I agree with their frustration with the term "the business" - I still prefer the term Business Operations in the definition.

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

- Yogish Pai