Gorillazation of SOA

Gorillazation of SOA
by Burc Oral

There are many ways to encounter the competition in the market place. Among my observations are many: leveraging product or brand characteristics like first-to-the market, best-of-the-breed, cheapest, etc.


I would like to add another one: Gorillazation. What is that?

Simple. Make it such a big, impossible endevaour that entry to the market is deterred. Show that you need a 800 pound gorilla to do the task. It must be complicated because we need humengous infrastructure, development teams, operations etc.

So, just happed that SOA was among the victims of gorillazaton to the point of utter complexity with dozen of standards which are still incomplete. What happened to KISS!

It was kept in the dungeons with the CORBA and was purely technical. This "technical" aspect dubbed SOA as Web Services and made it add a few pounds on the gorilla.

Less business awareness--because it is the techie gorilla-- is an effective way to keep competition away.

How about cooepetitive business environment: compete and cooperate. Our financial industry has been doing for a long time. Every penny eventually circulates across many financial institutions not because it likes to do but it is in its nature. So, fnancial organizations, for instance, communicate through clearing houses, check fro credit, transfer in-kind, etc. These are all commoditized services.

SOA is nether a complex beast nor a 800-pound gorilla. It is true that it tunes differently for many people (See SOA Many Things). When communicated well, Showever,OA can be easily understood and can gain alot of fans at the corner office.

Consider the relation between two verticals: time&attendance (T&A) and point of sale(PoS) . An employee entering her id at a point of sale (PoS) terminal can easily be used to verify attendance. This inherent relationship is the tip of a very powerful interplay of systems and can be expressed as a series of services between T&A and PoS. Often, the vendors are different in an organization. And, more frequently, after mergers and acquisitions, an organization can have multiple systems of T&A and PoS. This where business stakeholders do not want to incur costs due to rigidity of the applications and look for solutions that are pluggable and friendly to the world. Service-Orientedness with its implementation agnosticism becomes the valley of comfort.
Now, while there is a fierce competition in T&A and PoS vendors, they must talk to each other in order exchange information. Cooperation starts well with

When business stakeholders contemplate how to make systems work together, there is no room for gorillas!

Next, we will talk about democratization of business interplay as a direct out come of SOA.


Burc Oral
http://www.linkedin.com/in/burcoral







First

Business Architecture

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


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


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

Ashok Kumar

Vendors need to focus on providing practical (real) advice

Since the end of last year - I have had the opportunity to talk to a number of CIOs, Chief Architects and business executives for large enterprises and one of the constant frustration I have heard from the end-user community (IT organizations) is the lack of practical (real) advice from the vendor community.

Following is an example of a simple Business scenarios:

• In order to increase it's revenue Business Operations would like to learn more about the customer - to identify opportunities for cross-sell/up-sell.
• They approach their partners - typically their preferred SI and/or their preferred software vendors.
• Depending on the vendor (including SI - their resell relationship with the ISV) they would recommend a Data Warehouse, Business Intelligence, EAI and/or Master Data Management Solution. In addition, they will also be willing to guarantee, typically as a fixed bid, implementation within weeks/months (typically 3 to 6 months).
• Business buys into it - spend the money and a year later had not yet achieved the end-result they were promised.

Problem:

• Vendors focus on delivering an IT solution (generate the revenue and move on to the next project) instead of solving the business problem

Recommended Approach:

• As part of every engagement - both the SI and ISVs need to insist on conducting a Business workshop (prior to starting the IT implementation).
  
• Provide real-practical advices - example: for a customer master the vendor typically looks for decision from the business to provide them with direction on where to add the customer - Lead Management, Opportunity Management or Order Management. As the vendors have done multiple implementations - shouldn't they know the best practices in the vertical and recommend the approach?
• SI typically have separate organizations that deal with business transformations and IT (CRM/ERP )implementation teams. Shouldn't every engagement have folks from both the practices at the customer site during the initial stages? Agreed the engagement cost will be a bit higher for the customer - but the value received will be substantial greater than the up-front cost. I for one - would be willing to pay. My problem was that no one approached me with such a proposal. However, I was lucky - my CIO recommended (and funded) that I have a full-time architect(s) from an SI on my team.
  

Thanks to SOA - I am starting to see changes in the SI engagement models. They seem to these days more focus on Architecture & Approach first - before bringing in their implementers. However, I am yet to see this transition happening in the ISV community.

The above example is based on my own experience and the case study is available here. As the case study indicates - I had to solve the same problem twice. First implement and learn from my mistakes and then repeat it again later. If we had real advice - we would have got it right the first time.

- Yogish

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

Enabling Strategic IT through Services-Oriented Architecture

Lately there have been a flood of negative comments about Services-Oriented Architecture, especially about providing business value. In this blog I have attempted to provide a simple example on how SOA, if done right, could provide substantial value to the business for an enterprise.

Read more about this at my IT toolbox blog here.

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 -

Practitioners Opinion on the Role of a CTO

These days there are a lot of discussions on the role of the Chief Technology Officer (CTO), especially as large and small organizations are planning to leverage Information Technology in a strategic manner. As technology is changing at a very rapid pace, enterprises now have a unique ability to leverage them for providing innovative solution to leapfrog their competition. As the role of the CTO is relatively new, there are various roles CTOs play in an organization resulting in many senior executives expressing confusion about what is and should be the exact role of the CTO.

The objective of this Opinion paper to briefly describe my views on the role of the Chief Technology Officer and is roughly based on the white paper Role of the CTO: Four Models for Success by Tom Berray (Primary Author) and Raj Sampath (Secondary Author). Unlike their white paper in 2002 where they categories the CTO’s into four categories, my opinion is that in this current age CTOs need to have all these attributes.

Please click hear for the Opinion Paper.

A decision makers concern about ESB

Today everyone assumes that all IT organizations will procure an ESB whenever they decide to adopt SOA. This is true today, especially as the technologies and standards are not mature as yet. Following are a couple of comments/concerns that the decision makers had about ESB (yes! they did buy the product but their concerns are real).

On an average I already have 7 hops for providing my customer the relevant information whenever they login to my web site. Based on your reference architecture recommendation I would increase the number of hops. What does that do to the performance? Isn't that adding one more layer to the current architecture? - Chief Architect of a large Financial Company

Our strategy is to grow by acquisitions and with each acquisition we increase the number the data centers, each having thousands of Servers. In my opinion we are one acquisition away from disaster and you expect me to tie it together by leveraging and ESB? Why shouldn't I stay with my existing messaging infrastructure? - CTO of a large transportation company.

At the same time, to be competitive vendors are starting to include additional functionality into the ESB that do not belong there. In short, making it heavier requiring additional resources to implement the solution. Vendors have now also started pushing embedding ESB into each of the products (not a smart move).

In my opinion the ESB shall be irrelevant by 2010 for the following reasons:

• There is a push by end-users and vendors to develop standards (SCA) to decouple the business logic from the bindings. I expect this to result into a meta-data driven (SCA) container both for exposing services as well as referencing (invoking) services.
  
• Even though the some vendors do not yet decouple the logical name (such as "Credit Card Approval for Mortgage") from the physical name, the market will drive them there.
• As services are deployed into production, the SCA container shall leverage P2P technologies such as JXTA, Jini, UPnP and/or WS-Discovery to dynamically discover the dependent services. Newton is a prime example of such a container

I expect that by 2010 the SCA container shall eventually be the next generation container and unlike the JEE container will be independent of the technology implementation. This shall address the concerns of the decision makers about the ESB. No more need of additional hops (yes! the transformations shall be performed by the SCA Container).

Of-course like all previous waves and ESB will not go away but be used to interface with existing legacy systems. As for J2EE/JEE - they would still be the technology of choice for some of the SCA containers.

- Yogish