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 -

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 Agility and Business Driven EA Domain Models

For my presentation on the topic of SOA and Business Agility at the IC - local chapter event last month I had refined slightly the Business Agility Domain Model. The pdf version of slides on the domain model are available here and is based on my original blog on Defining and Measuring Business Agility. I have been planning for a long time to develop a spread sheet that goes along with - maybe someday I shall get to it.

Over the last few months I have helping my customers understand the role and importance of Enterprise Architecture and came up with this EA domain model (also referred to as the "circle of happiness" by one of my potential customer :) ).


The Business Driven Enterprise Architecture consists of the following domains:

• Business Architecture (or Business Design)
• Competency Center -Check out this SOA Podcast on SOA COE by Melvin Geer published by the SOA Consortium.
• Enterprise Architecture - check out all my blogs on this topic
• Governance - Corporate, IT, Enterprise Architecture, SOA and so on (whatever makes sense)
  
• Life cycle management includes all life cycles such as Program Management, Project (application) Life cycle, SOA Life cycle and Services Life cycle
• Finally - Environment Industrialization. We came up with this term at BEA-IT to ensure consistent systems environment through out the application life cycle. Systems environment included networks, firewalls, OS (versions and patches), servers, data centers and disaster recover sites for all environments from development to production.

Hope this was helpful and as always As always do feel free to drop me line with your comments and/or feedback.

- Yogish

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 -

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 -

Extending the use of Service Enabled Interfaces for dealing with Business Events

Typically Business Services are considered to be invoked in a synchronous request-response mode. Business Applications are supposedly called into action by human actors who leverage user interfaces. On the other hand, Business Processes are typically assumed to be triggered by Business Events.

However, it is possible to extend the use of Business Services and/or Business Applications to deal with Business Events. This enables the reuse of existing business logic and business rules in order to deal with new buisness interactions which are introduced into the ecosystem without needing to undertake a large service implementation effort.

For the purpose of this discussion Business Services, Business Processes and Business Applications will collectively be named as Event Response Interfaces. Business Events can be routed to the receipient Event Respsonse Interfaces by an ESB or a Message Hub. Business Events may also be sent to a Complex Event Processing Engine for aggregating, filtering or de-duping business events prior to routing them to the apporpriate Event Response Interfaces. Having said that, how does one extend existing Service Enabled Interfaces to trigger them asynchronously?

Architecturally, adding a Message Listener that in turn calls the Service Interface (such as seen in a Service Activator JEE pattern) or leveraging a Service Mediator (such as an ESB or a Message Hub) can allow Business Events to invoke Business Services or Business Applications outside of their regular request-response mode of interaction. The use of this simple architectural strategy allows Business Events to be processed by existing well tested Business Services or Business Applications.

One additional point to keep in mind in extending the interaction context from synchronous mode to that of an asynchronous mode is with regards to dealing with business exceptions, faults and business responses. In a synchrounous communication mode both of these are returned to the invoker of the business service or the business application. In an asynchrounous mode there is a disjointed execution context where in the invoker is not blocking on the call and waiting for execution control to be returned. The execution path may or may not be re-established.

To deal with this asynchrounous communication model the service response and faults may either be logged in a common repository or may be returned back to the invoker by the service mediator. The service mediator may re-establish the execution path with the invoker. The service mediator such as the ESB may refer to the Registry to find the originator or may leverage the correlation identifier and originator address in the payload (a provision made by the WS-Addressing spec. via the use of wsa:From metadata element).

Regardless of which architecture component is used i.e. an ESB, a message hub or a message listerner that intercepts the Event Response Interface the result is the reuse of the service behavior. In addition to reusing the business service applying this simple service extension technique also enables leveraging existing investments in infrastructure components such as the ESB or message hub thus helping achieve business agility.

Please provide me with feedback as to whether or not you have leveraged existing IT service assets to introduce new communications pathways.

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

Ideal IT organization structure for (SOA) enabling Business Agility

Based on some of the conversations with my peers as well as reading about the transformations happening in the IT organizations - following is an overview of an ideal IT Organization. This is more at a functional level and the reporting organization would be specific to their own business models, culture and of-course politics. Additional details are available here.

- Yogish

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 -

SOA Consortium: Keynote by Sandy Carter

The SOA Consortium's last 2 days face to face meeting for 2007 is currently underway at Burlingame, CA. Yesterday, Sandy Carter gave a keynote address to the attendees and following is a brief summary of her comments:

Every two years, IBM conducts an exhaustive CEO survey (a couple of hours conversation with each of the CEOs) which is published every two years (last years report is available here). The next report shall be published next year around April at their IMPACT event. Following are some of the interesting findings:

Business have notices a 2% improvement in their revenue by focusing on IT optimization and an 8% improvement by focusing on business optimization. However, when they align both IT and Business, the impact was more than double, 20% a key reason for enterprises to focus on Business Agility.

The top four areas of focus for CEOs (in no particular order) are:

a) Agility
b) New and changing customer
c) Business Model Innovation
d) SOA (Yes! looks like SOA had now made the CEOs priority list)

As there is no real way of measuring agility, IBM has coined a new term KAIs (Key Agility Indicator). This is similar to KPIs (Key Performance Indicators) and they do have a tool that allows to benchmark your results to the 12,000 company data that they have compiled.

I like the concept of the KAIs and agree that what IBM had done is great job putting together a tool that allows enterprises to benchmark themselves against the industry. However, I believe that there is a need for a simpler way to measure your own agility (an art and a science) and it for this reason, I had taken a crack at the Business Agility domain model. Hope to define the maturity levels for each of the Business Agility domain model to enable business that do not have access to IBM's KAI tool.

As for new and changing customers - I agree things are changing at such a rapid pace, it is difficult to keep up, especially with the new social networks tool which shall rapidly enter the enterprise market. Hey! I just looked at Loopt and realized one could use such as tool for logistics and asset tracking.

Business Model Innovation is happening now, especially in large enterprises. Examples: Cisco moved from direct sales model to channel sales model. Oracle's model now has changed their business model from being a technology leader to an aggressive acquirer. And of-course we have companies like Google, Facebook and LinkedIn that have changed the way we search and collaborate.

Best Practices - Mashups and the importance of Foundation Business Services

It seems like interactive web based social computing experience and SOA style services are not really thought of as related. However, when mashups are incorporated into the realm of the enterprise the need for ease of collaboration as well as accuracy tend to matter and this is where enterprise worthy services enter the picture.

In addition, having access to a registry is key. This SOA based infrastructure component becomes the central point for discovering loosely-coupled services that encapsulate core business functions and business semantics. To fully enable the knowledge worker in the selection of services for mashups, the business user community not only has to be included in the definition of the service but it has to be involved with the process of publishing these services to the registry as well. The reason being that business keywords that are used in describing the service are identified and entered when publishing the service to the registry. This level of cooperation and collaboration with the business user insures that the services are described using business language and grammer.

Finally, cross-business service payload validation behavior has to be put in place to prevent users from creating mashups that combine incompatible services. For instance, only services sharing related business contexts or those that return information at the same level of granularity should be allowed to be pulled together. Tools/ IDEs of the future that aid in the creation of mashups may be able to interrogate the categorization of business oriented services and informational metadata descriptors published into a registry or a repository to make a determination of inter-service compatibility. In the near term however, an enterprise will have to resort to governanace and testing policies to allow compatible types of services to be mashed up.

As can be seen in an enterprise context users can gain the capability to perform effective mashups when they can leverage reliable foundation services to access enterprise information systems. This way IT can enable user self-service by just making core services available to the knowledge worker and enhance business agility.

Your feedback is invaluable.
surekha -

Key Observations - Service Reusability - Does it really work?

From my experience, on SOA projects reuse was mostly accomplished with technical services/ infrastructure services. However, it is the business service reuse that we are struggling with as the Lines of Business (LoB)/ business units feel that their sub-set of the business logic is very unique. The problem is that most of these business services are rendered non-reusable due to the fact that they include both business logic and process sequencing logic into the same code base and it is the later that is unique to the LoB and not the business logic. Also, we have achieved greater degree of reusablitiy in terms of data access and informational services and not so much business function services that are a higher level class of services.

I would like to hear about what your experience has been with regards to service reusablity. Have you been able accomplish this.

Thanks,
surekha -

Defining and measuring Business Agility

In my previous post on defining Business Agility I had defined it as follows

Business Agility = Business Alignment + IT Flexibility

Business Alignment: Alignment between the various business units
IT Flexibility: Alignment between Business and IT + ability to rapidly deploy new business capability

Business Agility = Business Intuition + IT * (BPM + SOA)

Of course this definition is pretty generic and the next obvious question is how do we measure Business Agility? Typically most business have one primary measurement criteria - company
financial results such as revenue, operations cost, stock price and profits. There are alternate ways for measure business by adopting Six Sigma, Lean, etc. Again this approach is still business focused - and does not help in measuring IT Flexibility (especially as very rarely have I see IT organizations actually adopt Lean, Six Sigma or any such measuring criteria - maybe that will change :) ).

After giving this much thought I came up with this domain model for measuring Business Agility.

The Business Agility would be measured against each of the following domains:

Business Strategy (Business):

• Business Strategy clearly defined and communicated
• Clear defined goals for objectives for each of the business units
• Responsibility and Accountability
• Enterprise culture
• Innovation capability

Operations Framework (Business):

• Alignment of the business unit objectives to the enterprise objectives
• Alignment of operations teams across business silos
• Accountability and measurement of delivery to enterprise goals, rather than business unit goals
• Global Business Process definitions with localization capabilities
• Politics and interaction between business units
• Major part of compensation liked to enterprise goals, rather than business unit goals.

Information Strategy (Business):

• Identified clearly information needs for supporting business process
• Identified common business entities/objects such as customers, products, orders and partners that span business processes and silos
• Classified data into reference, transactional, master and analytics
• Information Governance for managing common data across business units

Governance (Business & IT)

• Business Governance (details to follow later)
• IT Governance (details to follow later)

Branding (Business & IT)

• Business Branding (customer, web site, multi-channel, products, etc.)
• IT Branding (Business perception, customer/partner perception, IT staff, etc.)

Technology Strategy (IT)

• Developing IT Roadmap (SOA Blueprinting, Standards, Architecture, etc.)
• Current state (baseline)
• Future/Target state
• Technology Roadmap aligned to business priorities

Program Management (IT)

• Program Management Office
• Application life cycle
• Application Portfolio Management
• SOA life cycle
• IT Governance (SOA Governance)

IT Operations Maturity (IT)

• CMM Level
• ITIL adoption
• SLAs
• Business Continuity
• Infrastructure maturity

These are defined at a very board level and need to be drilled down to identify or develop a maturity model for each of these domains.

- Yogish -

Key Learnings - Living Business Driven SOA

There are some significant challeges in getting business buy-in on supporting SOA. Back in August my work in obtaining this support was recorded in the following interview with Jennifer Zaino of bITa Planet.

The opening statements of the interview are as follows:

"Some of the Words of advice from the frontlines: One IT leader discusses the challenges of getting business buy-in for service-orientated architecture (SOA)."

Please read the complete list of this conversation:

http://www.bitaplanet.com/alignment/article.php/3694846

I would love to hear you views on this matter.
surekha -

Defining Business Agility

There has and continues to be a lot of discussion around Business Agility and following is how I would define Business Agility

Business Agility = Business Alignment + IT Flexibility

Business Alignment: Alignment between the various business units
IT Flexibility: Alignment between Business and IT + ability to rapidly deploy new business capability

My observation has been that business is pretty flexible and has the capability to create a new business model effectively, if required (of course under the right leadership). The real challenges are IT's ability to integrating the new business model with the existing infrastructure. My experience has been that adopting SOA enables IT flexible to adapt to these changing business models.

Business Agility could also be defined as:

Business Agility = Business Intuition + IT * (Business Alignment + Flexibility)

Business Intuition: A common sense approach for aligning the various business unit

Business Agility = Business Intuition + IT * (BPM + SOA)

BPM: for aligning IT with the Business (yes! the business defined the business process but it is the business analyst - typically from IT captures this. Very rarely have I seen business actualy use a BPM tool for modeling business processes)
SOA: for providing flexibility