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 Learnings:Drawing parallels between Design Patterns and the principles of SOA - Part II

This blog entry attempts to expand on the concepts explored in a prior blog of mine Key Learnings: Drawing parallels between Design Patterns and the principles of SOA that deals the relevance of design patterns in the world of SOA and services. Patterns explored previously were the Facade, Abstract Factory, Builder, Factory and Bridge.

In this blog we look at how infrastructure components like the ESB that are part of the service mediation layer insulate the service consumer from the service provider by offering call-dispatch functions that map out the most efficient call execution path for honoring a consumer business request। Many of the constructs of the service mediation layer provide add-on capabilities which are in fact model driven implementations of common design patterns।


Adapter - modifies an incoming method call to fit the required method signature or definition of the provider without impacting the consumer

Transformer - adapts the parameter and return type or message format (which includes alteration or interpretation of the message content) and enables the insulation of the consumer information from that of the providers'

Decorator - augments the behavior or is a facility to add on to the behavior without altering the interface and breaking the service interface and service contract as new consumers need additions to the base business behavior

Interceptor - provides ancillary behavior, filters out information or calls to the provider, validates the message content for authN credentials, authZ/ entitlements and permissions etc। all of which provide important ancillary behavior to the provider without having the providers' service implementation layer having to be peppered with nonbusiness logic level code।

Finally, the point of this blog is to show that despite vast numbers of changes in technologies and technology based service offerings the basic design principles and design patterns of the object oriented design realm are still applicable। Knowing these and applying these carefully enables one to retain the durability of the service interface and protects the consumers from unexpected or non-deterministic results and exceptions.

Thank you for listening. Your input is invaluable!

- 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 -

Architecture tenets of High Cohesion and Loose Coupling

Architecture tenets of High Cohesion and Loose Coupling – Both of these tenets are related to one construct i.e. that of a “Contract”.

The term contract in information technology involves the definition of high level interfaces in the form of a coarse-grained set of operations that have well known inputs, output, clear exceptions or faults. The contract hides all of the details of implementation and allows these hidden implementation details to behave as one cohesive unit - in that it provides support for "high cohesion". By extension, in separating the client or consumer or caller of the contract from the implementation details it provides support for “loose coupling”.

This concept of contract works at any of the following levels:
1. sub-system interface (for example, a persistence sub-system)
2. component interface (for example, a remote monitor)
3. layers of architecture (for example, business layer vs. presentation layer)
4. infrastructure service (for example, a messaging service)
5. SOA style business service (an customer account self-service)

Furthermore, the concept works whether the implementation is a local call or a remote component call long as the "contract" is honored. Experienced architects also insist on unidirectional contract-based communication even between the layers of the architecture - with communication only being allowed to the very next layer down. The concept is that the more volatile layers interact with the more stable layers’ contract without skipping levels. This level of indirection adds as a check for the entire system as the volatility of top level layers and the communications from the volatile layers’ are limited to the very adjacent layer alone without affecting multiple aspects of the system when these layers change.

This concept is the key driver of the Model View Controller or MVC pattern wherein the presentation layer is allowed to talk to the interface or contract of the controller layer or the façade layer alone but not to the interface in the business logic layer or the data logic layer. Also, the façade layer or the controller layer is not allowed to communicate to the client or the presentation layer. The contract dictates that it is the client or the presentation layer that is responsible for initiating the communication.

Advantages of adhering to the Contract:
A) Implementation details can change without negatively affecting the consumer or the client. Loose coupling facilitated by the contract protects the client or consumer. Also, since the behavior is highly cohesive (all hidden behind the contract in one well-knit codebase) any alterations to business rules or behavioral logic is embedded in this codebase, thus insuring the completeness of apply the rule/ logic change. Without this it is very possible that part of the logic is embedded in consumer codebase and part of it may also be placed in the communication or the mediation layer (leading to the anti-pattern low cohesion and high coupling).
B) System integration testing and performance optimizations are easier when there is a known finite set of operations, inputs and outputs that will be allowed by the contract.
C) Understanding the interactions and invocations for the consumer becomes easier due to the known and pre-configured set of operations that are published on the contract. This helps to make the system or application more deterministic.
D) As long as the contract is not broken in making behavioral enhancements new consumers can be entertained without having to create newer versions of the codebase. Of course, this can also mean addition of newer audit and tracking capabilities in compliance with internal or regulatory policies without affecting or "informing" the consumer.
E) Since the consumer is not interacting with multiple internal points of the codebase, the system interactions and resource utilizations per consumer/ client call are more quantifiable and predictable. This makes it easy to scale the system for availability. This contract or interface then becomes the single point of entry for all interactions and is thus the only point that needs to be monitored to assess system resource utilizations. In addition, provisioning of system resources becomes more scientific as all calls of a certain operation take a known amount of time and resources given that the inputs are also quantifiable.

As can be seen, a simple construct such as “Design by Contract” when taken seriously and to its logical conclusion renders a great deal of architectural stability, robustness and extensibility.

As always your comments are welcome.
surekha -

Semantics in the realm of SOA and Services

The following whitepaper of mine delves into the topic of semantics in the realm of SOA and services.


http://www.soablueprint.com/yahoo_site_admin/assets/docs/SUITPOpinion_Roles_of_Semantics_in_Services_and_SOA.15781752.pdf

An area that I have not explored in the whitepaper is the usage of semantics to “discover” service offerings that are needed to deal with the "out of ordinary" alternate execution paths. It is true that today most of our processes are deterministic and follow a known or predetermined execution path. Any deviation from this deterministic execution path is typically handled by raising an exception or by routing the deviant information to a work flow component for human intervention. In future however, “runtime dynamic discovery” of services could be based on semantics that embed service ontology and process based state machine metadata - all of which work together in a business area to enable finding dynamic alternate execution paths that could be invoked to resolve “out of the ordinary” and exception situations.

As always your feedback on these thoughts and on the whitepaper content are invaluable.

Surekha -

Enterprise Service Bus vs. Service Component Architecture

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

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

Now back to the ESB vs. SCA topic.

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

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

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

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

Your comments on this topic are invaluable.
surekha -

Why you need a stated "service versioning policy"?

I felt I needed to expound on the topic of service versioning after I heard concerns from a few CIO level executives about needing to "support" multiple service versions. The reason stated was that maintaining multiple service versions was expensive from both a hardware and on-going support perspective.

I completely support this opinion in that if left "unchecked" - read without the right level of governance - this could turn into a maintenence nightmare (not to mention a regulatory hazard especially if the regulatory policies are not implemented uniformly across all versions). But then this is a case for having governance and not an argument against supporting service versioning policy.


I attempt to outline some reasons for defining and publishing a "service versioning policy" to support both the business need and to create an efficient resource-utilization operating model. A carefully thought out strategy of service versioning that is rigousously "governed" allows us to do some of the following:

1. support multiple versions where in business functionality may be altered based on the operating business context or business area or industry vertical
2. support multiple versions based on the user community needs (for example, invoking a service that incorporates work-flow rules vs. needing a service that is invoked as part of an automated process level interaction)
3. support multiple versions that allow an enterprise to reduce the risk to the business when introducing new business behavior or new business process optimization changes
4. support multiple versions of a service that allow the enterprise to incorporate and interject additional authorization, entitlement and audit related rules that change based on the business context and/or business user role
5. support multiple versions that allow the system administrators to provision server resources appropriately based on the QoS/SLA needs of the service consumer and the service contract definitions.
6. support multiple versions of a service to isolate more expensive business behavior calls to specific versions so as to reduce impact to all of the other consumers (For example, a version with externalized business rules while the business is "testing" a new rule would be less performant than a version where the business rule is ratified and encoded into the business logic layer. In this example the business behavior is externalized making the service version more flexible but this makes the service less performant)

Finally, I think that service versioning can be used as a strategy to both support the business need and to optimize resource utilization that in turn make consumer interactions more efficient. Thus, the "appropriate service version" is invoked based on the "right" business context.

Your comments on this topic are invaluable.

Thanks.

surekha -

Key Learnings : The End of the Application

This is a blog post in response to Todd Biske's posting on "The End of the Application" which can be found at the following URL.
http://www.biske.com/blog/?p=347

******************************************************************************
I am in complete agreement with you Todd, about needing a retirement plan for the term "application"!!! I share your sentiment about how this ubiquitous term reflects not only the siloed solution that gets built but also in how this term influences the way in which the business need is translated into requirements. Case in point is the way in which I have heard business analysts phrase their questions to the end-user. For example, "How do you expect to act on the information the application provides?" as opposed to asking "How do you or your user community make decisions based on this information?" OR "What is the business context (business rules, policies,regulations etc.) that influence the information?". The business analysts sould divorce themselves from thinking about the application as the "sole repository" of the information and it's current limitations. Analyzing the business user needs and the decision making process might help them discover that these business rules may have already been implemented elsewhere and that the "application" is but one component needed in delivering the targeted business capability. Sadly,this is not the case.


Part of the reason for gravitating toward point solutions and monolithic deployments is the sense of control the solution owner has on the entire solution stack and the confidence factor of knowing that a customized deployment has a better chance of meeting the response time SLAs. It is my hope that the availability of robust standards based deployment platforms may help resolve some of these latent fears. The key however is to recognize that the usage of the term application does influence the final implementation of the solution. Given this, there is ample justification for doing away with the term "application" as it may be too limiting in the realm of today's highly interconnected enterprise.

Doing this may lead to the required behavior change that is needed to move away from the creation of monolithic applications. As suggested by you Todd we may need to be more conscious of the term we use and this could be a simple matter of using a prefix to the term application or it may be that we have to throw the term away altogether. I propose using a prefix of "composite" to qualify the term application to get this desired change in behavior!!


The term application should be semantically equivalent to "applying" a
unique business context to the usage of a common asset such as a business service, legacy system or a business process. This "application" (note,the verb) of value-added business context is focused on delivering a crucial business behavior that offers competitive advantage to the enterprise. With that definition in mind, the term "application" may get a lease for life when used within the purview of the concept of "composite application" that suggests "distributed solution assembly" instead of "monolithic solution creation". Composite applications are mechanisms that help deliver novel business capabilities that are typically translated to"novel" assembly of reusable business services where by the composite application layer performs business context value-addition.


This assembly of business services within a composite application (as opposed to the creation of a monolithic application) enables the enterprise to realize "speed to market" gains from SOA. It also enables an enterprise to move to a model where the enterprise obtains base business services (off the shelf or SaaS style) and uses the composite application layer to apply the enterprise specific business context with the idea of offering distinct flavors of service offerings; thus moving away from the "creation" of solutions to "provisioning" of solutions. (It is worth noting that composite applications are not just deployed in the business layer but also
in the presentation layer in the form of Web 2.0 style mashups.) Finally, I feel that the only way we can move away from the mode of "monolithic point solutioning" to a mode of "assembling solutions" is by making the move to the concept of "composite application" as it breaks the existings emantics associated with the term "application". Following this mindset switch we may be able to completely replace this term as knowledge workers develop a comfort level in both the efficacy of "assembling solutions" at the same time that the vendors build up deployment platforms to help IT meet the stringent SLA needs that are demanded by the business.
***********************************************************************************

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 -

Separation of service interface from service implementation

The pattern defined below attempts to increase an enterprise' chance of adopting SOA and insures the success of service orientation by reusing existing IT assets. These assets include leveraging existing legacy applications and well tested business logic or else could be the reuse of investments made in vendor package product installations.

________________________________________________________________________________

Separation of service interface from service implementation while leveraging existing IT assets

One of the key architecture tenants of SOA is the concept of separation of service interface from that of the service implementation. This concept although very simple is a very difficult one to put in practice. In this blog are discussed a few possible patterns that can be leveraged to loosely couple the service interface layer from the service implementation layer especially if these service interactions are within an industry vertical that are part of a business use case or interaction scenario common to that industry vertical. For instance, online auctioning and bidding interaction in the retail vertical. Loan approval based interactions in the financial services vertical.

In general, ESB vendors have tried to do this by proposing mediation flows that conform to the Service Broker and Service Gateway patterns. The Service Broker pattern leverages the ESB mediation flow to send requests to the appropriate service implementation(s) based on some type of mapping between the service interface and the service implementation. This information could either be wired into the ESB mediation flow or could be obtained from a service repository or metadata repository. On the other hand, the Service Gateway pattern leverages federated ESB mediation flows to send requests to the appropriate service implementation even when these implementations lie outside the firewalls or the enterprise boundaries. The Service Gateway pattern could be used for both extranet based service implementations and to communicate with external partners, agencies and SaaS style service providers. Both Service Broker and Service Gateway interactions may work well for an enterprise level service interaction or even for a specific extended enterprise level service interaction.

The following service pattern could fall into the category of industry vertical specific service interactions. The assumption is that both consumers and providers in a target industry are able to come to an agreement on common service interface definitions that apply to the interactions required by the industry vertical. However, the question would remain as to whether the service providers would be expected to re-architect their entire implementation layer, not to mention competitive advantage in having optimized product implementations.

An option would be to repurpose their service implementation layer by creating point to point adapters (such as the JCA style adapters). Our collective experience shows that the adapter soon becomes ridden with complex business logic such as business validation and transformation logic. An attempt is being made provide alternate options via the use of metadata and generic service patterns to deal with this predicament.

Use of industry specific schema based payload

This pattern proposes using industry-specific payload schemas that hold metadata such as a "service descriptor" and "properties descriptors" for service payloads. The “service descriptor” provides the definitions for a searchable metatag. Both the “service descriptor” and the “properties descriptors” are defined using industry-specific schemas and govern how this information is populated by service consumer.

The presence of the service descriptor metatag in the payload would allow the ESB mediation layer or a Service Router layer to generically route calls to the appropriate service implementation end-points. The service descriptor metatag can also be used to optimize Service Router specific "find" and "redirect to the service implementation layer" algorithms. Again, the “find” and “redirect” algorithms would be fine-tuned in keeping with the industry vertical specific interactions. Thus, any service implementation end-point that can map its' service semantics and service behavior to the value in the service descriptor can honor the service request even when its' own high level service facade does not conform to the "externally published" service interface.

Here the service implementation layer is expected to be able to satisfy a service request that takes the form of a business event or else would be in the form of an incoming message over a messaging pipeline. The key is that the service implementation layer call is not an RPC style API call (which would/ could require the use of a business adapter). The ESB mediator layer can at the most perform protocol translation but is not required to do more than a simple message format transformation (if needed) for interacting with a service implementation layer even though it does not map to the industry compliant service interface.

The pattern also prescribes the use of the industry-specific payload schema that has “property descriptors” that govern how the service consumer populates the payload. This schema not only provides placeholders for encapsulating service consumer business usage context but also defines the request parameter properties and the response payload properties. The property descriptors also have information on how to handle the payload semantically. The use of industry-specific payload schemas allows the transformation of the payloads to be optimized via the use of standard utilities or appliance plug-ins. These optimizations can be applied at the service mediation layer or at the service router layer. The model makes it possible to achieve processing efficiencies at the level of request and response payload creation and consumption.

In the event, the service implementation layer cannot deal with the industry-specific payload definitions then these optimized transformation algorithms could be leveraged to adapt the payload into a service implementation specific construct. This transformation can be undertaken either at the service router layer or ESB mediation layer or even at the service façade layer (i.e. at the entry-point into the service implementation layer).

Again, given that the interaction is going to be message-oriented and not an RPC based API call this pattern when leveraged would insure that the implementation of service provider does not have to be completely re-factored. This statement holds true as long as the service implementation layer honors the service behavior and is compliant with response semantics expected by the consumer.

Among the key benefits of this pattern is the fact that the industry vertical can agree to and publish service interaction semantics via the use of metadata that are embedded in the service payload. This enables all parties to interpret the service request and the service responses in an unambiguous manner.

________________________________________________________________________________
As always your feedback is invaluable.
surekha -

Key Best Practice: Separation of concerns - the age old best practice!!!

Here I thought that reiterating the principles of separation of concerns would provide a great rrefresher.


It is my contention that architecturally it is a good idea to keep the persistence layer and the business logic layer separated just as it is to keep the presenation layer and the business logic layer separated. Especially, in the age of SOA this make a great deal of sense as it enables each layer to change independantly to enhance the overall agility and robustness of the solution and to increase the responsiveness to the business needs. Here I expound on the reasons for the separation of the persistence layer from that of the business logic layer.

A) Keeping the business logic from being comingled in the same objects that hold persistable fields (that are tied to the persistence store layout or database schema) is important as this separation of the persistence fields from the business logic allows the application/ component to deal with the changes to the database schema more efficiently. The corrolary is also true in that persistence related objects/entities are insulated from the changes to the business logic.

B) The separation of the business behavior from the persistence layer may have an added advantage of allowing the implementation and testing of the business behavior to remain independant of the implementation and testing of the persistence behavior.

C) In addition, these persistence related domain entities could become simple state encapsulation entities (DTOs) and could become the sole constructs that are traded/ exchanged between the persistence layer and the business logic layer

D) These state encapsulation entities (DTOs) could also be shared as parameters between components and/or applications and could be transformed into XML long as they all belong to the same business domain.


Your feedback is appreciated.

surekha -

Key Learnings: Canonical Models vs. Domain Models

In this blog my attempt is to provide some definitions and in turn to get feedback on the differentiation between the parameters traded between a service consumer and a service provider (Canonical Models) vs. the parameters traded between the various internal architectural layers of an application (i.e. the Domain Models).


Canonical Models
Example of canonical models - Customer Preferences, Supplier Profile , Vendor Service Offerings and Accepted Service Bid

1) Shared as parameters for trading between service consumers and service providers
2) In SOA context these are typically transformed into syntax agnostic and platform neutral XML
3)Business Service usage context is associated (for example, information about a quote vs. a final offer that has legal implications is embedded in the canonical model)
4) No real business logic is embedded giving service provider the freedom to alter the behavior without breaking the service contract
5) Cross-business domain relationships formulated by representing multiple business concepts are included so that the consumer can avoid making multiple remote calls

Domain Models
Example of domain entity - Purchase Order and Customer

1) Shared as parameters between persistence layer and business logic layer
2) May or may not be expressed as XML especially if traded within the business domain applications/components
3) Domain context and domain internal relationships are captured
4) Domain specific business logic may be encapsulated as the model is traded within the business application or within the business domain. Also, the business logic in the domain entity has relevance internally to the business domain alone.
5) Single business context and only relevant amount of information in terms of attributes and relationships are represented so as to avoid hydrating a large volume of information into memory.


Thanks in advance for your feedback.
surekha -

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 -

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 -

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 Learnings - Profile of a Business Service

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

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

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

Your feedback is appreciated.

- surekha -

Semantics and its' role in Business Services

Role and importance of semantics in the context of services and SOA:

Semantics refer to interpretation of information and not the literal definition of information/ data. Applying semantics to information turns it into “knowledge”. Semantics is the act of applying references and drawing conclusions given a set of more scientific informational constructs. Typically semantics are derived using the context in which information is presented. Transposition on the other hand allows applies the rule of inference where in one can draw conclusions on the implication of truth based on some set of facts.


By deduction semantics and semantic transposition deals with alternate inferences being drawn from one or more data and informational constructs using business rules. Inferences of this nature are not completely predictable as the rules used to arrive at the interpretation may or may not be quantifiable and/or may not be codified into a business rule.


The biggest risk in dealing with semantics is the lack of predictability of the outcome of an interaction, whether manual or automated. The reason is that the rules driving the decision tree or the execution path are not quantifiable.


Despite the complexity of interactions brought about by semantics and the complexity in being able to interpret these to codify and execute alternate behavioral patterns, one can attempt to capture metadata and leverage naming conventions to make the service based interaction more predictable. These guidelines may either be applied within an enterprise or could even have applicability to govern service interactions within an industry vertical.


In the realm of services, semantics drive both the discovery of services and also the execution paths and alternate process logic that is undertaken by the service provider. Naming conventions and expected service behavioral guidelines govern candidate service descriptions. Having documented behavioral implications and constraints associated with these naming conventions make the service “discovery” of a service and the expected interaction with the service provider more predictable from the service consumers perspective. These service naming conventions also act as metadata that can be used to publish information about the service definition during the publication and registry process.


Furthermore, one could make the assumption that there are certain features of a service action that denote the type of expected behavior, notwithstanding the type of business concept or the business function being manipulated by the service invocation. The service business action verb component can be associated with the general description of the type of behavioral patterns a consumer can expect. Given that SOA style services follow design by contract principles the naming and the signature of the service definition or description does not bind or affect the manner in which the service is implemented. This metadata of the verb does not impact communications patterns internally used by the service or even the informational model or informational exchange pathways that might internally be used by the service. These details are left up to the service provider. Having action verb nails expected behavioral semantics (inquiry only vs. alteration of service information model state) and not implementation semantics. Also, the action verb points to expected interaction semantics (one way/ two way/ guaranteed delivery etc.) and not the implementation model used by the service provider.


The key is that having these kinds of action-verb semantics outlined makes the service usage more specific. The service based action/ verb may be used by the consumer to identify the right service to use during the process of discovery. Also, the provider can use the action/verb notation to inform the consumer about the implications of the information being returned.


For example, a service operation called “obtainLoanRate()” with a action/verb embedded as the service invocation metadata may inform the consumer that the information being returned in not legally binding on the service provider. On the other hand, using the “lock” action/verb in the service invocation metadata “obtainLoanRate()” implies that the service provider is locking the rate and that the consumer is also bound legally to non-repudiation of the “rate” being locked. In this case, the semantics of the verb can be used by the consumer context to pick the right service depending on the usage context on the consumer tier. In addition the action/verb pairing may be used by the provider to insure that the right application logic is invoked. For instance, when the service consumer calls with a “get” action/verb invocation context the service provider implementation layer may go through fewer rigors and processing cycles than would be the case when the service consumer calls with a “lock” action/ verb invocation context.

Another example of the metadata driving semantics is the use of business context field by the service provider. A service operation “getCustomerProfile()” that uses the context of “Customer Profitability” or “Customer Credit Rating” could alter the information being returned in the payload of Customer Profiles. The service provider uses the service usage contextual information provided by the consumer to decide what type of information is returned to the consumer. The consumer context allows the service provider to alter the information returned between providing “Customer Profitability Range” or the “Customer Credit Score” in the customer profile.


As has been mentioned semantics can be applied to both the service publication and service discovery process. As part of the service publication process (to the registry) the service provider may use metadata in order to express the need for more precise contextual information to drive the way the service provider interprets the request. The service provider may add this constraint to leverage this information for altering the returned payload. The service consumer may also be able to use this business context metadata provided by the service provider along with the service provider business action-verb name to derive information about expected behavior of the service provider and how the request might be interpreted. For instance, a service operation that has an action-verb called “preview” may inform the service consumer that the information may not be reliable or even persisted beyond the current session while having a service consumer invoke a service operation with an action/verb “reserve” indicates to the consumer that the information returned is persisted beyond the current session. This naming convention is indicative of the service provider confidence factor in the consumption of the information being returned by the service provider.


In addition having some area for capturing the concept of the consumer context may help the service provider apply this knowledge to execute alternate paths of the business use case scenario. To some small extent, semantic transposition can be achieved by incorporating rules that have been gleaned from observing human behavior. If these manual workflows and best practices can be captured then these business rules can be used to execute alternate flows in the service. Consumer context information can then be used to invoke alternate business functionality and/or pathways that are known at compile time but may be loaded at runtime or invoked at run time on an as-needed basis.


The behavior altering ability can help the provider to honor consumer requests with more precision and with greater compliance to the contracted SLAs. This may also enable the service provider to roll out more behavior without altering the information models being exchanged and without altering the service interface. This may be a mechanism to curb the service version sprawl!!


Finally, the business context that is expected by the service provider or the business context information and candidate service name as published by the service provider could be classified as "service usage semantics". The purpose of the service usage semantics is to inform the service a consumer about the possibility of semantic variations in the honoring of service call.


Issues in incorporating Semantics in the realm of services and SOA


Semantics and "Semantic Transposition" may be fairly complicated to achieve in business systems. Most applications/services are typically written to fall cleanly into the “known” process logic pathways with no ability of either interpreting independent unrelated pieces of information. All paths typically have to be known and defined at compile time. In most situations, semantic interpretation may be complicated enough or unique enough to only be undertaken manually by knowledge workers. However, there may be a small subset of cases where the interpretations and inferences that drawn by the knowledge workers may be codified into rules and contextual metadata to help in the execution of alternate flows of a business use case.


Impact of semantics on Web Services, Service Registry and Service Repositories


As the concept of SOA and SOA style services become more standardized service related metadata registries/ repositories such as UDDI hosting web service URLs, service contract definitions and service descriptors defined as WSDL may make provisions to allow a service provider to publish service usage semantics, standard classifications and ontologies. These sets of metadata may become a guide in aiding the service consumers to browse for and find services more intelligently.


Furthermore, having a standardized mechanism to express the semantic usage information may enable tools to automatically bring this information back when service consumers are browsing for potential services. It must be noted that if this information is just some comment or a open ended description field instead of it being a structured metatag with known enumeration of values then browsing and searching for services cannot be automated.


Each industry vertical may have different values that might be populated into the standard structure to help with automating the search. These fields and valid industry vertical enumeration of values could all be published into the UDDI registry to help the consumer in either formulating the request or in informing the consumer about how to process the response.Some sample metatags could include fields such as business area field (Credit/ Sales/ Logistics).One such specification that is addressing Semantics in the realm of services is the Semantic Annotations for WSDL specification. http://www.w3.org/2002/ws/sawsdl/.


Conclusion


Having some stringency bound in using naming convention and in creating the request canonical models allows execution of the right sub-set of the service behavior thus making the service interaction more optimal. The presence of semantic oriented metadata allows the service provider to alter the behavior being executed in response to a service invocation and/or alters the amount and type of information returned to the service consumer.


Although not applicable in all situations, having contextual information and action/verb usage metadata information enables semantic transposition and execution of alternative service provider behavior s without having to resort to the execution of a human workflow and manual intervention. The objective of associating semantics to action verbs or in associating consumer context is not to bypass human intervention always but to use the learning obtained from the knowledge worker and encapsulate it in process automation logic.