Showing posts from May, 2008

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

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

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

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 teamsWhite Paper on Business ArchitectureWhite 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 architectur…

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 teamNo existing Enterprise Architecture team
Once the decision is made for outsourcing the EA team, the next obvious question is what shou…

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 "go…

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

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