Enterprise Architecture (EA) team's role in Solution Delivery

Hello Fellow Architects - I am writing this blog in response to Todd Biske's blog entry on the fact that Enterprise Architecture Must Assist in Delivery.  I am in complete agreement with Todd on this aspect of EA's role in the enterprise.  Participating in delivery of business solutions is a value add that cannot be discounted. Not only does it add to the credibility to EA but it allows EA to be viewed as an ally which makes it easy for it to stay in touch with the "goings-on" in the enterprise.  This partnership and visibility is key to start identifying cross-domain synergies and cross-business process impacts across all the granular projects.

As the leader of EA I have tried to instill this behavior in my team.  My team is now seen as a much more "useful" partner by delivery and not just as a "watch-dog".  Some of this perception change was a result of EA working with delivery in coming up with practical multi-step solutions/ alternatives to EA standards compliance. We reached out to the delivery teams that were under a severe time crunch to come up with Remedial Action plans that incorporated tolerable architecture compromises that would not jeopardize the stability and flexibility of the solution while still delivering business value (on-time!!).  Putting such intermediate architecture solutions in place with hooks for building upon these architecture constructs increased buy-in from both application delivery teams and their business partners.  The result the business partners got to test a more robust solution and were willing to give the project team adequate time in the next phase.  In addition, we were "invited" to review plans for the next phase where we could inspect the program plans that included time to work on the agreed upon architecture compliance roadmap. I have to admit that EA did go down to a much more technical design level for helping with the integration and infrastructure to be able to communicate our architecture roadmap and recommendations. 

EA achieved not just inclusion in the process but also this forced our architects to stay in touch with reality.  This education for our Enterprise Architects allowed us to understand both limitations and constraints of the enterprise and also the technology.  Learnings from this experience were then taken into consideration in refining the technical reference implementation for the EA strategy. Finally, this education has enabled EA to be a more formidable team that was able to bring this knowledge to evaluate vendor "marketecture" thus keeping irrelevant products out of the enterprise.


Your feedback is invaluable.

Thanks.

Surekha,

Architetcure in 2009

This will be my first entry into the blog for 2009. It has been a while due to a lot of churn over last few months. I am happy to see 2008 go. The only fear I have is that at the end of 2009, I don’t want to be longing for 2008. What a brutal year. I am hoping that people have learnt some lessons that you can not always focus on short term results at the expense of doing the right thing that has long term value. Architecture falls in that long term value category, yet first thing organizations do when it comes to cutting costs - they sacrifice architecture. Why do we keep rewarding people that cause untold harm in the long run while seemingly achieving short term goals? Most IT organizations fall into the same category. Senior executives are rewarded based on short term gains or operational efficiencies at the expense of long term viability. Current environment will only exasperate the situation.

It seems to me that executives and boards have not met the responsibilities entrusted upon them. Most executives have only been interested in benefiting themselves. I believe that executive bonuses should be kept in escrow and only be handed out at least 3-5 years after they are eligible to receive it. The disbursement of bonuses should be contingent on meeting some tough criteria where it is clear that no long term harm was brought upon by actions of these executives that may have fattened the bottom line in one year but killed the company over long haul.

My apologies for ranting but it has been very frustrating last few months. Now we need to focus on future and adjust accordingly. One trend I am seeing is that without clear, measurable ROI, funding is going to be scarce. There are fewer (if any) opportunities to experiment. This also means that vendors will have to adjust their expectations and will have to prove beyond power point slides that their product is worth investing in.

Happy new year everyone.

Ashok Kumar

Doing a lot more with a lot less in the current environment

Given the current market conditions all business executives are once again challenging the technology teams to do a lot more with lot less. Following are some of my thoughts around this (nothing new - just going back to the basics).

• Focus on solving your customers needs - independent of the industry.
• Do not scale back on innovation. All markets typically are different when they come out of a recession that what they were before one. It is only those who focus on innovation shall come out as winners.
• Focus on your core business - differ the adjacent market until the market recovers (unless it is related to the innovation)
• Do not focus on developing new infrastructure (unless absolutely needed). Build out the infrastructure incrementally as new products and offerings are either upgraded and rolled out to customers.
• Do invest heavily on large packaged applications. As the entire market is going through a shift - it may not be wise to invest in large packaged applications. It will consume a lot of resources (and $$$) without any major differentiation. It may be easier to subscribe for the same applications from a SaaS provider.
• Do invest in a few strategic initiatives
• Do not attempt to crawl before you run - "run baby run". The company that runs the fastest to meet the customers demand WILL WIN.

Just some of my final thoughts to close out 2008 and as usual please do feel free to drop me line with your comments and/or feedback.

Wishing everyone a very happy and prosperous new year.

Yogish

Architecture Organization Patterns

Over the past couple of years I have observed that companies from the high-tech industry are adopting two distinct patterns for organizing their architecture team.

Centralized Organization:

• This is true for most IT organizations led by a CTO-IT, VP EA or Chief Enterprise Architect
• All EA members reports to the head of the EA team
• Individual EA are either focused on some core technology, IT functions (such as networks and operations) and Business Domain
• Business Domain Architects dotted line report the head of LOB-IT (typically the Divisional CIO)
• LOB-IT may also have Architects who dotted line report to the member of the EA team

As IT organizations need to focus on what is best for the enterprise - rather than on individual business units, this is a preferred organization structure adopted by IT organizations.

Federated Organization:

• Most of the High-Tech companies have adopted this model for their line business (with IT adopting the Centralized Organization)
  
• Typically there is a Chief Architect for the company who reports to the CTO of the organization
• Evey business unit has a Chief Architect who directly reports to the Head of Engineering of the business unit and dotted line to the Chief Architect or the company.
  
• The Chief Architect sometime reports directly to the GM of the Business Unit.
  
• The GM of the Business Unit and the CTO typically report to the CEO
• The head of engineering reports to the GM or is also the head of the Business Unit (varies - no consistent pattern observed)
• The success or failure of this pattern is directly dependent on the leadership skills of the Chief Architect of the Company
• The Chief Architects of the Business Units also play an important role and will be effective only if they constantly communicate to each other
  

As the GM like to have a sense of ownership - this organization pattern makes sense of the High-Tech industry. If the Architecture team is centralized under one Chief Architect - my observation has been that the GM then hire their own Chief Architect (under some other title) which creates a huge organization conflicts.

Some Interesting Observation:

• One of the companies during the transformational phases transferred all their key resources - including development managers, developers, DBAs, Operations, etc. to the architecture team. Made a public statement that Architecture team was core - reorganized the rest of the teams and later over the three year period transferred the folks back out to the new organization. Using the Architecture team to retain the best resources during their transformation phase.
  
• There is a 50% split between Shared resources team as being part of the Architecture team or an independent team.
  
• Lately over the last 12 months - a lot more companies in the Silicon Valley are looking or Chief Architects responsible for both Business and Technology Architecture. However, they do not explicitly mention Business Architecture in their job description but their job description includes Business Architecture responsibilities.

Just some of my observation about the Architecture Organization Patterns and as usual please do feel free to drop me line with your comments and/or feedback.

Yogish

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 -

Enterprise Architecture, BPM, SOA and Master Data Management (MDM)

One of the best practices for Enterprise Architecture teams to redo the enterprise road map on a periodic basis. It is typically reviewed and updated during the yearly budgeting cycle and my preference is to perform this activity every 18 months. The best practices (and the traditional approach) is to first document the as-is, next develop the target or future state (architecture) and finally develop a short term (6 months), mid term (12 months) and long term (18 months) road map. Preferable an actionable road map that ties back to the business initiatives.

It is good to document the the as-is (or current reality) from all the domains such as Business Context, Applications, Technology, organization and Funding. Typically the business context is best understood by identifying and mapping the key business processes at a high-level.


This approach not only helps have a common vocabulary between business and IT by identifying the key business processes, it also helps identify the key enterprise data objects (entities) such as Customers, Contacts, Products and orders. Based on the priorities of the each of the business process, the next steps would be to drill down into one or all the business processes as illustrated below.
Once again, it is not necessary to use a Business Process Modeling tool (however, using one would be helpful later), the objectives is to clearly identify and document the next level of details. The next steps are to perform the gap analysis on each of the activities as illustrated below.

This approach enables both business and IT clearly visualize the existing gaps, impact areas and cost estimates which helps in developing the priorities and the investment plan. In addition, it is also important to identify and illustrate the list of applications/solutions that support a given business process as well as it perception within Business and IT as illustrated below.
As we develop the actionable road map to the future state, one this is obvious, no matter what we implement or adopt, whether it is a packaged applications, BPM or SOA key enterprise data crosses the silos both from an organization and the applications. It is for this reason, there is a critical need for adoption Master Data Management across the enterprises.

It is very important to spend sometime understanding and mapping these enterprise data objects in the context of the business process. It would also be very helpful to also develop a high-level data model and transaction (CRUD) matrix associated with the business process before initiating the activity of selecting/implementing an MDM solution.

I have seen a lot examples where companies have embarked on an MDM project without developing the architecture (see my blog on Blueprinting Information Architecture for more details) and not meeting the desired business outcome. The two other primary reasons of MDM failures are:

• Lack of developing the data governance model up front that involves all the impacted business units
  
• Assuming that a packaged applications could be modified to be the master data for enterprise.
  

To keep this blog short, I plan to blog more about my thought on BPM & SOA later and please do feel free to review my CDI-MDM Summit presentation on my experience with MDM/CDI.

As usual please do feel free to drop me line with your comments and/or feedback.

- Yogish

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

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

This is what EA teams do best

Recently there has been some discussions on a few forums/groups on the role and responsibilities of Enterprise Architecture Team. As I was going though my previous presentation to the IT leadership team, I came across these slide that I had presented in 2003. Thought it was still relevant for today's discussion.

I used these slide to start the discussion on the need for developing an EA road map and also help increase by headcount to include Information and Infrastructure Architects for which I had no coverage. Yes! I did get the incremental head-count.

As reference you may also want to check my previous blogs on:

• Best Practice: Establishing EA teams
• White Paper on Business Architecture
• White Paper on the Role of a CTO

- Yogish

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 -

Should Enterprise Archtiecture function be outsourced?

Enterprise Architecture is considered strategic by most of the CIO and the interesting question is should the EA function be outsourced ? If the EA team clearly demonstrate value to both the business and IT leadership teams, it does not make sense to consider this. However, not all EA teams are successful and following are some of the trigger points that could get the CIO to start thinking about outsourcing the EA team:

• The EA team establishes standards and primarily acts a police for the enterprise mandating that all business units/projects comply to the standards.
  
• The LOB-IT completely ignores the EA team and makes it's own decision (does not care about the EA team) and most of the time, it is not compliant to the EA standards.
  
• EA team not involved in implementation of any strategic projects by any of the business units.
• Constant churn in the EA team
• No existing Enterprise Architecture team
  

Once the decision is made for outsourcing the EA team, the next obvious question is what should the structure be the outsourced EA team?

Following are some of the key learnings based on my experience:

• Do not out source the entire EA function to a single SI, especially as this would conflict with the dual objectives given to the acting EAs. One given by the customer (develop the most optimum Architecture) and the other by their employers (generate as much services revenue as possible). For organizations where EA teams do not exists, it definitely makes sense for bring in an SI to run this function and later hire people to develop this capability in-house.
• Keep EA management function in-house.
• Have a dedicated EA from one of the major SI as part of the team. This is to bring outside perspective and also a resource who could tap into the SI vast knowledge bases and resources. Based on the budget - I would be tempted to have two EAs - one from each of the major SIs providing services. Competition breeds excellence.
• Have at least one dedicated EA from your major vendors (software, hardware, network) that provide mission critical capability. Negotiate the rates and the resources before signing the major deal and please do not accept the vendor sales commitment to have a dedicated pre-sales resource assigned to the account. Put it into the contract.
• Have the lead technical resource from each of the major initiative be part of the EA team. Example: An SI may be developing a Supply Chain solution and in this case - the lead architect from the SI for this project should be part of the EA team.
• Engage part-time vendor resources on an as needed basis. Example: Once the content management solution is deployed globally, engage the vendor architect to review all major changes.
• Establish a Business Architecture team, ideally from a Management Consulting company or SI that is not providing the technical architect resource to the EA team.
• Establish, communicate and update EA standards, processes, governance, roles, etc.
• Be transparent - i.e. share your budget as well as all vendor proposals with the entire team.
  

The EA team members could all be outsources (on contract) or could be a blend of both employees and contractors. Depending on the situation, it may not be a bad idea to have all EA resources as contractors but make sure the management function is in-house.

Agreed this is contrary to the popular opinion - but something that could be pulled off with the right leadership.

- Yogish

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 -

Business Architecture Dialogue

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

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

Will let you know how it turned out.

Ashok

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 -

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

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: Establishing Enterprise Architecture Teams

In one of my previous post I had published the first draft of the presentation on Establishing the Enterprise Architecture team. Based on some feedback and my own experience, I have now updated it with the following additional details:

1. The strategic role of the EA team
2. Enterprise Blueprinting benefits and guidelines
3. Enterprise Architecture Review process

and finally the EA domain model from the SOA Consortium EA 2010 effort. Please click here for the pdf version and do drop me a line at feedback@soablueprint.com for the PowerPoint version.

- Yogish -

Best Practices: Establishing Enterprise Architecture Teams

Recently I have had a number of conversation with some key decision makers of various IT organizations and the common questions I got asked was to explain the process of establishing enterprise architecture teams.


This first requires the understanding the various IT organization patterns (models) as well as the evolution (maturity*) of the EA teams. My initial thoughts on this are available here.

Based on the feedback / comments from the community, I plan to take it to the next level of document the entry and exit criteria as well as the deliverable by the EA teams though each of phases.










* As there are already a lot of maturity models out there have decided to stay away from that term