Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural principle is considered in proposing architectural solutions. However, there is a distinct benefit to using both paradigms in unison in solving business problems!!


Business events are the "core concept" that drive any EDA implementation. On the other hand, decoupling business applications and the business functions/ business processes embedded in these business applications is the core theme of SOA. SOA implementations rely on the use of standards based web services technology stack and that of canonical business documents (XML) .

However, it is my contention that an enterprise that does not invest in the web services or ESB technology can still leverage EDA style business events to implement loosely coupled business services provided it makes an effort to analyze its' business events and creates canonical representations of these key business events. This could mean defining business events that encapsulate a business concept that have an associated business concept state indicator or a business action indicator. Further, these business events can be used to trigger constructs such as event handlers that act as a facade or layer of indirection to execute a business function via the use of an application API.

It must be noted that the terms event producers and event consumers or publishers/ subscribers are being used loosely to denote the initiator of the event and the owner of the business behavior that "knows" how to deal with the event. In a SOA realm this would be the service consumer and the service provider respectively.

The key to this model in leveraging SOA is the use of self-describing canonical business events that are subscribed to by independent event listeners. These event listeners and/or event handlers that are delegated to by these event listeners help insulate the event producers and event consumers from the complexity of knowing how to interpret the events. Here the event producers/ publishers and event consumers/ subscribers are decoupled from one another via the use of canonical business events as well as messaging technologies.

Either of the two layers i.e. the event publisher or event subscribers can be altered long as the contract is adhered to in terms of the canonical business events. Also, messaging technology oriented configuration consoles allow the definition of the event publisher/ subscribers to be connected via metadata as opposed to hard-wiring these in code. Event handlers act as event adapters in that these could translate the event and invoke the required API call to deal with the event. The event handlers act as a business facade that hide the workings of the business application and allows the business application to change without affecting the event producers.

To recap, if loose-coupling is a core SOA principle that promotes business agility then the use of event handlers invoked using messaging technology and canonical business events can be used to deliver this goal. The enterprise does not need to invest in a SOAP stack right away to achieve this goal. If desired technology standardization and interoperability can be introduced at a later phase by turning these event handlers into web services. This two phased approach defined above enables the enterprise in pushing off investment in the technology stack to a future phase without sacrificing business agility and/or offering novel business capabilities.

 
Please feel free to drop me a note.
thanks.
surekha -

Business Event Subscriber Responsibility?

Thought I would write a comment about what are some of the expectations of a business event subscriber.  These would be rules that the business event publisher could depend on.  These sets of rules form the basis for Event Driven Architecture (EDA) based implementations.

Subscribers of business events and business alert notifications often assume that the business event publisher is responsible for insuring that duplicate events and any repeat alert notifications are suppressed. However, to protect itself the subscriber has to be able to "analyze" the business event to determine if the erroneous event/ alert was sent by the business event provider, messaging architecture or the enterprise service gateway. The subscriber (business application, business process) would have to "know" when to discard the business event as being a duplicate event, as well as when to re-apply the same business event, which could have been issued as a result of change in the business policy or due to an increase in the business alert thresholds.  Knowing when an event transmission is real versus a false notification insures that the outcome of the EDA implementations are valid.

For instance, if a "low inventory alert" is received by the Purchasing Process it may react to this alert notification by transmitting a PO to the supplier. However, if the same Purchasing Process gets a second alert a few seconds or a few minutes later chances are the Purchasing Process may choose to ignore this. Not examining the alert more closely may cause it to erroneously discard the alert.  It is possible that in order to optimize and tune the response processing the subscription process just looks at the product and quantity to de-dup alerts received within a certain period thus causing the second alert to be discarded. The business impact of ignoring the second alert was failure to increase in the "minimum product level". The bottom line, the subscribing process has to know how to differentiate between fundamental business rule changes and duplicate alerts and not have a compute process optimization overrule business policies.

In general, in an event driven architecture realm the disconnectedness of the publisher/ subscriber pair places a burden on both parties to insure that there exists a mechanism and rules to enable "semantic" translation of the message payload that carries the business event or the business alert.  Without investing in the definition and analysis of these semantics benefits of the loose coupling EDA architecture would deliver a scalable technical architecture model but would not yield the right business outcome.

It must be noted that standards such as WS Eventing, WS Base Notificaitons and WS Notification help to define WSDL and XML Schemas for defining the mechanics of loosely coupled and inter-operable EDA implementations but the business semantics and rules in constructing and consuming the events are not really well laid out.  Not having had exposure to specifications such as ebXml and OAGIS business documents I assume some of the B2B interactions may have more mature semantic definition but for the most part I think these rules of engagement may still need to be fleshed out by the participating parties.

Thoughts and feedback on this topic would be very useful.
surekha -

Service granularity and service reuse - why information semantics are key?

In the following blog which refers to the Amazon CEO's "letter to the share holders" one is truly amazed to read about how the Amazon team constructs a single product detail page from a combination of 200 to 300 services!!

Amazon architects may have truly found a way to identify the right level of service granularity to combine these into composite service offerings - without causing the information in the combined service to be distorted. This so called semantic dissonance has led many of us architects to create coarse grained services which preserve the quality of information but at the cost of reuse!

This is the the balancing act of how to define a service with the right grain of information encapsulated in it such that once it is combined with another service the combined service is still able to deliver meaningful information at the same grain of the originally combined services.  This is what we mean by semantics that govern how to combine two or more granular services to create a meaningful composite service which continues to encapsulate information that is valid and accurate.  It may be technically possible to create a composite or a single course grained service starting from two granular services (long as the canonical models/ payload have common elements) but the combination may overlook key business constraints, business rules, regulations and algorithms that render the final response invalid and inaccurate.  

A very simple example, combining product sales of a region with product marketing dollars to yield a service that delivers marketing efficacy may be a great new service concept.  However, if the product sales service does not provide information about the tenure of the product company by region or the presence of similar competitor products by region then the marketing efficacy service is not able to account for lift in the sales accurately.  The reason being marketing efficacy service cannot appropriately reflect the efficacy of the marketing dollar as being attributed to the "novelty" factor (where in the product is the first to enter the market in this region, or else if the product has a very attractive "entry price point" as it's debut to this new region).  Both of these artificially show that the marketing campaign strategy is far more successful than it might really be.  The price and novelty had more to do with the sales lift. 

 

The use of information by the business to make strategic decisions and the study of information flow across lines of business and the alignment of business information to strategic business activities is key to business architecture. By extension we find that it is in the realm of business architecture to govern service interactions and the creation of composite strategies to guard against semantic dissonance. 

Please share with me your thoughts.

surekha -

 

Should Architects aspire to be Product Managers?

One of the interesting trends I am observing is that Architectures aspiring to be Product Managers. Have recently come across multiple PM who were architects and have also been approached my a few who are interested in becoming one.

Following are my thoughts on when Architects should consider PM as their career path.

1. A true Business Architect with the ability to map the technology strategy to align with the Business Strategy
2. Good understanding and hopefully first hand experience interacting with the real customer (not the business units)
3. Good understanding of revenue and business model
4. Passionate and believe about the role of the products in the customers life (whatever they are using the product for)
5. Ability to influence cross-functional team and get everyone passionate and focused on the product
6. Willing to change course mid-stream based on customer/market feedback
7. Ability to ride up and down the market roller coaster
8. Ability to keep singularly focused on an single product/portfolio

Do not take on the role:

1. by assuming that PM get to define the product and every one else will follow without any questions (the PM is responsible for bringing every one on board)
2. consider whether one would be a great Architect vs. a good Product Manager (focus on what one is better at doing - a great advise given to me by my manager)
3. do not want to deal with constant communication with customers / leadership teams
4. assume that the grass is greener there - doing what one does best shall reap the right rewards

Just my point of view and this could also apply for taking on a role of a Business Liaison in an IT organizations.

- Yogish

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 -

SOA is not.....

Looks like there is a contant need to educate the industry on SOA and this time I shall take a stab at what SOA is not....

1. SOA is not about technology
2. Web Services is not SOA
3. SOA is not dead - it has the same symptoms as global warming (too much pollution in the air)
4. SOA is not defined as "A camel is a horse desinged by a committee"
5. It is not a case of Chicken (Business Architecture) and the egg (SOA)
6. SOA is not entirely about reuse
7. SOA is not expensive - it follows Archimede's Priciples :)
8. SOA is not a product or a platform
9. SOA is not about registry & repository
10. SOA does not start with a big bang

Just my thoughts and please do feel free to drop me line with your comments and/or feedback.

Yogish

Thoughts on Finding Value in BPM/Workflow Technology

I found an interesting entry on my colleague Todd Biske's blog Finding Value in BPM/Workflow Technology.

Here are some additional thoughts on how the value proposition for the BPM and Work Flow Management tools could be taken to the next level.
1) Ability to incorporate "Rules" or a "Rules Engine Component" into a business process step or a work flow task would be a great addition to these BPM/ Work Flow Engines. These rules can be encoded best practices or they can be regulatory in nature or business algorithms that may be volatile while the process flow or the work flow may not be so.

2) Ability to perform impact analysis for any process flow change prior to releasing the "new process".

3) Availability of analytical tools that could suggest optimization opportunities that could make process improvement suggestions such as the following
a) how switching the steps in the process may benefit the overall process flow
b) how metrics show that there is a ton of waiting in a step that could be made optional based on some criteria
c) how analytics could drive other optimizations such as making suggestions for automation of an information gathering step

4) Ability to subscribe to regulatory bodies that govern the outcome of a particular step of the process flow.

5) Ability to create a business process template for oft used processes within an industry vertical that allow standardization in the overall flow while catering for customizations and competitive advantage optimizations in particular steps of the flow.


Best Regards!!
- 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

Key Best Practices - What is Service Orientation?

What is Service Orientation?

1. It is the ability to use of simple business syntax for defining and discovering business services whose interfaces encode business behavior using the business language
2. It is the ability to define a business service policy that governs the avaialbilty and reliability aspects of the business service

Service Orientation most of all is about the use of simple business terms defining business offerings that execute business capabilities. 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!! The need for web service standards, SOA infrastructures technical stacks including HTTP, URIs or SOAP/ HTTP and WSDL enter the picture only when talking about the how to achieve Service Orientation, not the what is Service Orientation!

The technology is undoubtedly important provided an enterprise has the discipline of Business Architecture in place to define its' business service portfolio. In addition to this, the business service portfolio represents an enterprise' unique interpretation of Service Orientation and this enables the enterprise to deliver the strategic capabilities that are sought by the business. These strategic business capabilities are delivered as business service offerings that lead to market differentiation opportunities.

Without undertaking an effort to leverage in the Business Architecture discipline an enterprise has IT investments in technology of ESBs, the Service Registry and Service Repository etc. but the Web Services that are published look more like API calls. These API like web service interfaces will befuddle the business and will not help the enterprise realize the full potential of "Service Orientation". As would be noticed Service Orientation is built right into the concept of Service Oriented Architecture (SOA).

WOA and SOA are both architecture models that speak to the implementation models for achieving "Service Orientation".

WOA is a way of taking the REST-like service interface concepts that involve the invocation of standard operations that act upon simple payload identifiers and are transmitted over standardized internet protocols. The WOA paradigm embeds complexity in the "message format" or the payload. In other words, WOA prescribes a clean architecture model that enables an enterprise to quickly expose services with information constructs represented as URIs (instead of complex XML Schemas). Furthermore, the interfaces are defined as simple HTTP commands of "GET, POST, PUT and DELETE". It must be reiterated that the key point of the WOA model is to abstracted away complexity behind the simple interfaces and URIs. This aspect of simplifying the interface is very much in keeping with one of the principles of Service Orientation. However, this model may not really meet the other tenet of Service Orientation i.e. interfaces are represented using business vocabulary and are codified using business syntax.

SOA on the other hand is an architecture paradigm that leverages a more complex message format (that is defined as XML Schemas) with the interface definition that is could be deemed more business-like. Here the complexity of the message construct is codified using XML Schemas. These XML Schemas encode the business-document structural rules but do not expose the complexity of the business rules. So to some extent SOA meets the other Service Orientation tenant in keeping service interface definitions more business-like long as the interface definitions are driven by business architecture process.

WOA or SOA do not by themselves address the governance and monitoring of the business service policy. SOA infrastructure is needed to address service policy monitoring, service clustering and scalability concerns. In addition, the use of service infrastructure components such as ESB service-mediation flows enables IT to achieve location transparancy of business services that indirectly influence business service availability. It must be remembered that SOA infrastructure products are important to the business only in that they help meet the business’ service availability needs.

Just because the business does not need to be exposed to the implementation details does not mean that IT has the luxury of glossing over how the enterprise deals with transaction management rules and the incorporation of the ever changing regulatory business rules. It is just that these complexitites are left up to the technical and operations experts in the IT area.

An important aspect in talking about the maturity of SOA based technologies is that most commercial SOA infrastructure component vendors are striving to comply with the WS-* standards. This level of standardization promotes interoperability of the SOA based infrastructure components even when purchased from multiple vendors. The effect of this interoperability is that it finally affords IT a chance to now purchase packages to implement these complex implementation behaviors (such as transaction managment, service monitoring, service management and deployment, regulatory and security business rule interception etc.) as opposed to having to implement these complex implementation behaviors from ground-up. Now IT has a way of aligning its' business serivce delivery model to achieve the business need at the speed of the business instead of having to deal with infrastructure and integration issues.

Whether a WOA model or a SOA model is used to define and deliver the business capability to the business does not impact the concept of Service Orientation. The use of the WOA/ SOA constructs do not add a competitive business edge. They are just best practice architecture models that add to the reliablility of the service delivery aspect.

Your feedback is invaluable.
Thanks.
surekha -

Legacy Business Processes and Business Architecture

Today’s reality is that most if not all of the businesses of any significant size have legacy systems and processes and we do not have the luxury of creating a business architecture from scratch. Any business architecture effort must take this fact into account. In a legacy dominated world, one of the difficulties in creating business architecture is having to deal with the processes that have evolved around the limitations imposed by technology. In such environment, a typical business process may involve multiple steps where the user must manually gather information from multiple sources, restructure/refine the information in a excel spreadsheet (or a paper) and upload into another system for further activity.

In such situations the business process reflects the problems associated with the underlying technology, where data is not integrated and/or is of poor quality. Additionally, applications supporting the business process are inadequate. This might be a good opportunity to re-engineer the business process and not simply automate the manual steps. At the same time, the representation of business design (business architecture) must reflect the current state.

I think it is important to have a good understanding of the business events that initiate business processes and the outcome of the process. Capturing of business events and how a business reacts to such events should be an important component of any business architecture.

Ashok Kumar

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

Business Architecture

I have been having intense discussions lately on the topic of Business Architecture. I have looked at TOGAF, Zachman and other sources to find out what the experts are saying. I have also been talking abbout this with my colleagues at SOA Consortium to see what they have been doing in this area. It appears that while we all understand IT Architecture fairly well, there is less clarity when it comes to Business Architecture. Is it Process Modeling, Value Chain Analysis or something else that constitutes Business Architecture?


We can all agree that the purpose of any Architecture is to manage change. In order to manage business change effectively, we need to understand how a business is designed. It is this understanding of the design of business that is essential in managing business change. Additionalyy, there must be active management of a business design otherwise business design has very little vaklue. The bottom line is that some form of business architecture exists in every business simply due to the fact that a business is operating, producing goods or services and serving its stakeholders. What is generally missing is the formal representation and management of the business design.


I would propose that Business Architecture therefore is both formal representation of a business' design and associated processes and organizational structure to manage the on going evolution of the business' design. The question is what is the right way to represent a business design. A number of approaches are available including Process Modeling, Business Motivation Modeling, Value Chain Analysis, Six Sigma, Lean etc. Similarily what are the right processes and organizational elements that can yield an effective business architecture. I dont thins there is a single answer to this questions. We will explore this further in future postings.

Ashok Kumar

Key Learnings: Drawing parallals between Design Patterns and the priniciples of SOA

In looking through some of the Object Oriented Design Patterns, I found a curious parallal between the goals of some of the "Structural Patterns" and "Creational Patterns" and those of SOA.

The following are the two key principles that are most striking:
Principle 1: provide a clean interface or an entry point and hide all of the details from the caller
Principle 2: provide a layer of indirection between the interface and that of the implementation

It is interesting to see how these "design level" goals re-appear in the realm of architecture with changes only to the scale of applicability.

Principle 1 is supported by design patterns such as Facade, Abstract Factory, Builder and the Factory. Facade hides the behavioral details of the implementation while the others hide details of the details of the creation of a resource or assembly of a resource as in the case of "Builder".

Priniciple 2 is supported by the Bridge pattern that allows the plugging and replacing of any implementation long as the interface is supported.

The idea is not to arrive at a comprehensive mapping of the principles and design patterns but just to do enough to lend support for the core theme being presented here. This leads to only one conclusion, SOA does not preclude the use of good OOAD techniques. SOA just takes these concepts further into the realm of business architecture and business analysis to insure reusability and enterprise wide applicability of the IT asset, in this case a "service". SOA also has been lent support by the standardization of platform agnostic protocols and message model (such as SOAP/ HTTP) and the use of canonical business models (such as XML Schema backed XML).

Your comments are invaluable.
surekha -

Business Architecture Dialogue

I will be participating in SOA-Consortium conference being held in Washington DC from March 12-13. One of the main topic I will be focusing on is "Business Architecture". As a result of EA 2010 working group, we have identified Business Architecture as an important aspect of Enterprise Architecture. One of the problems is that there is no clear understanding of what the BA is and how an enterprise should go about creating one.

Surekha Durvasula and myself will be leading a discussion panel to get particpants to talk about their understanding or lack of understanding of BA. Being in Washington, I am sure the dialogue will involve public sector's take on this topic. It will be interesting to see how some of these concepts translate in a public sector settings.

Will let you know how it turned out.

Ashok

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

Business Process vs. Business Service

The purpose of this blog is to get some validation for how I look at Business Processes vs. Business Services. In simple terms, I differentiate between these concepts in the following manner:


Business Process
1) Triggered by business events
2) Issues a series of business actions that could involve the invocation of one or more granular business services
3) Interactions involve execution of a business activity that is representative of a value chain or is a core part of a value chain in the enterprise

Business Service
1) Typically triggered by a request from an online consumer or a single business transaction
2) Issues a single business action for the most part
3) Interactions involve the execution of a single business function or an inquiry against a single core business entity

Your feedback is invaluable.
surekha -

SOA Consortium: Keynote by Amit Sinha (plus 2nd day comments)

Amit Sinha, VP Portfolio Marking from SAP presented the key note on the second day of the SOA Consortium face to face meeting held last week at Burlingame, CA. The topic he presented was on Business Network Transformation and following are some highlights from his presentation:



Most of these observations were based on the survey of over 175 CIOs globally. The trend has been that IT organizations are transformation themselves from Operational Excellence to Business Agility which in tech speak would be from Integrated Enterprises to Business Networks. Instead of developing solution based on the "Built to Last", the IT solutions now being considered (funded) are being "Built to Adapt".



Following are the top three approaches adopted by the various IT Organizations:

1. Managing Relationship (Single view of the customer, customer focused solutions, etc.). 23% of those surveyed adopted this approach which resulted in approximately 7x growth / year
2. Cost Containment (IT operational excellence, Off-shoring, BPO, etc.) 23% and the results are well know in the industry
3. Business Process Innovation (change the business model) 14% surveyed are adopting this approach and are consistently observing 2x the growth compared to the industry

In short - SOA is actually a catalyst for Innovation.

Following the key note we spent the rest of the day discussing the SOA Planning Framework, SOA Center Of Excellence as well SOA Skill sets required. One consistent theme throughout was that there is a desperate need of people with excellent Business breadth and deep technology skills - also referred to as the T shared person by Sandy Carter (IBM).

An observation while reviewing the EA 2010 presentation:

Improving IT Efficiency: 2% improvement to the margin

Going through Business Transformation: 8% improvement to the margin

Adopting SOA that facilities both Business and IT transformation: 20% improvement to the margin

Having an Enterprise Architecture team with both Business and Technology Architecture Skills: Priceless

- Yogish

Best Practices - Is Canonical XML dying? - Reply to IC Blog

This posting is a reply to the blog posting on Canonical Model http://www.icmembers.org/blog/zaki/2007/10/5/is-canonical-xml-dying#comments



In general, I agree with the posting on Canonical XML discussion. I wanted to make a couple of additional comments on industry-vertical specific Canonical models and the benefits they offer to those enterprises whose interactions leverage standards based information exchange.



a) implementations leveraging package products that exchange canonical models expressed in XML allow ease of upgrading and/or switching between package products without paying a huge upgrade penalty. This is so in the case of functionality related upgrades that do not alter the service definition and/or the information exchanged. Also, this makes decommisioning of redundant packages easy when this becomes necessary during acquisitions long as the package implementation are all standard canonical XML based.



b) partner collaborations also become easy, reliable and robust when collboration is based on the use of common industry vertical XML representations. Adding more trading partners becomes easy when using standards based information representations and this in turn leads to predicatable interaction patterns and information exchange.



c) documentation that refers to common service interactions that form the basis of that industry vertical when captured in training artifacts enable standardized interpretation of the material. In addition, given that this type of training is transferable between enterprises belonging to that industry vertical sharing personnel among trading partners is also made simpler.

Your comments on the canonical model usage is appreciated.
surekha -

Key Lessons – The new and improved Enterprise Architecture Group

When invited to start the Enterprise Architecture Group a couple years ago my only thoughts were how to technologically implement SOA and EDA as the core architectural principles. However, soon enough came the realization that without having access to those who had sound business knowledge and those that knew the core business domains, value streams and the strategic business capabilities it would not be possible to effectively deliver SOA or EDA.


Service orientation of business behavior encapsulated in business applications and the definition of business events that initiate key business processes both require enterprise-wide understanding of business behaviors and business activities. Furthermore, the ability for identifying business services and/or business events comes from being able to abstract business needs that cross business domain boundaries. These skills can be found in a group of individuals being called business architects – a unique group of individuals who can translate the strategic business needs into an action plans that show how to enhance current business processes that support core value streams.


This led me to find resources that could analyze business processes (a.k.a. Process Architecture discipline) and resources that could analyze business information-flow, the value-addition pathways (where by business information is enhanced as it is exchanged across multiple business domains) (a.k.a. Information Architecture discipline). Both sets of these resources have allowed me to embark on true SOA style service definition. So the “new and improved” Enterprise Architecture Group has Process Architecture, Information Architecture (or what the industry calls Business Architecture) and Technical Architecture representatives.


Finally a note about the Technical Architects; my opinion is that, standards are vital but then if the Enterprise Architecture Group is unable to demonstrate the right use of standards in a true production environment this group will be left with very little credibility or be deemed the “ivory tower” group.


Having a cross-functional group of resources has made the Enterprise Architecture Group to be a well rounded group. The Business Architects of the group are in dialogue with the business as they can speak to the business in its lingo while the Technical Architects of the group are able to work with the developers as they are able to demonstrate the use of technology for building and delivering stable, performant and reusable services. The end result is that the individuals of Enterprise Architecture Group are openly invited to the table for consultations and recommendations.


I would love to hear of other organizational patterns/ formats that have enabled implementation of SOA and EDA.

Thanks.
surekha -