Showing posts from 2005

Direction for the SOA Wave

The Fourth Wave Barreling In

The impact of SOA, the fourth wave of enterprise IT, has gone way beyond the early adopters. Leading research reports show that the vast majority of CIOs and CTOs have formally explored, and in many cases begun implementing, pilot initiatives. Recent surveys conducted by InfoWorld, Yankee Group, and others show that over 75% of CIOs have investigated and are planning SOA investments in the next 12 to 18 months.

Despite the growing enthusiasm, SOA lacks many of the shared experiences, artifacts and patterns required for widespread and reliable IT adoption. Moreover, without a common language and industry blueprints, this wave, which promises benefits of intra- and inter-enterprise services reuse as well as process interoperability, will dissipate and eventually fizzle – ultimately only adding more custom logic and methodologies to the IT legacy. Directing the SOA wave so that it can live up to its potential requires user community leadership.


Recommended Approach to SOA

It is the best of times, it is the worst of times, it is the time of service-oriented architecture (SOA), it is a time of traditional development methodologies, it is a time when products have matured, it is a time when products don't exist yet, it is the season of the optimist, it is the season of pessimist. We have endless possibilities in front of us, but we are concerned about being irrelevant. We are going to achieve the state of nirvana, we are going directly the other way—in short, this is a huge opportunity for IT to demonstrate its true value.

Read more about this at

SOA Stakeholders

Indentify the SOA stakeholders for crafting the right message tothem.

Copy of my post at:

The consistent feedback I have been receiving over the past few months is requesting for a consistent definition of SOA. The messaging shall wary based on the target audience and is key to getting buyin to adopt SOA enterprisewide.
I shall attempt to identify the key SOA stakeholders and shall post the proposed messaging is the subsequent blogs.

IT "Board of Directors" Just like every organizations has a Board of Directors, IT needs one too. Typically this function is performed by some key executives or by their representatives. The Board's objective is to set direction, approve initiatives/projects, resolve conflicts, etc. Some organizations refer to these boards as ISSC (IS Steering Committe), ITRB (IT Review Board), etc.

Chief Information Officer (CIO) Head of the IT organization - responsible for all aspec…

Is ESB the same as an EAI?

The fundamental question that a lot of folks are asking is whether ESB (Enterprise Service Bus) the same (or the next Generation of) as EAI (Enterprise Application Integration). My response to this is no:

EAI is still appropriate wherever it makes sense (but I would not take this approach any more). The architecture approach is ADAPTOR-->TRANSFORMATION--->BUSINESS PROCESS -->TRANSFORMATION--->ADAPTOR which leverages EAI tool like TIBCO, WebMethods, WLI, etc. Is this truly SOA? No! - it is basically a point-to-point implementation on a Hub. The developer of the process need worry about all the protocol translation, routing, etc. and this is generally tightly coupled with the business process.

ESB on the other hand decouples the protocol translation, message/event routing, limited message validation, etc. and is targetted for use by IT Operations. Developers need not worry about all these details, which makes it faster to roll out new services. However, to make this a vaiable …

IT Engagement Model

One of the key ingrediance for success is clearly defining the roles and responsibilities within IT. There are multiple stake holders in IT with each doing their best to provide the highest level of support to the business. Most of the time this results in people stepping over each other - especially as there generally is a not a clear definition of everyone's task. Most of the project failures are due to the confusion is the definition of the roles between the PMO, Project Manager and the Enterprise Architects, resulting in resposiblities overlap and lack of making decisions. Gartner has produced an excellent job of defining the IT engagement modelat a very high-level and is independent whether organizations adopt SOA or not.

SOA - Development Organization

The benefits of Service Oriented Architecture (SOA) are not only reducing the Total Cost of Ownership (TCO) by reusing service, streamlining business process, etc. - it also reduces the total number of resources required to adopt SOA enterprise wide. The SOA - Development Organization shall generally be identical to the deployment model and by distributing the tasks by the tiers IT organizations shall need fewer very skilled resources (Presentation).

The Architecture Framework lays the foundation for the enterprise and the Agile Project Management enables large organizations successfully manage and deploy SOA enterprise wide. Without adopting either - the traditional (structured) development methodology and process does not enable enterprises achieve the full benefit.

SOA - Focus Areas

Following are the 8 SOA Focus areas that Executives need to consider while adopting SOA.
Governance & OrganizationStandard BodiesRegulation & ComplianceManagement (of Programs, Projects, Services, Infrastructure, etc.)Security (could be considered as part of management - best broken out seperately)Business ProcessDevelopment tools and MethodologyDeployment tools and MethodologyBased on my discussion with BEA there are 4 Organization patterns/models (listed in the white paper available at These models could be considered as:Centralized, Hierarchial, Federated & Partially Federated and these models are typically structured the same way the Enterprise is organized. For example is the business is highly-centralized - then so is IT. This structure would typically not change for adopting SOA across the enterprise. Forrester has an excellent research paper on this - which you may want to download from their site.It is easier to …

Defining SOA

Service Oriented Architecture means different things to different folks. To an IT Architect, it means the overall enterprise archtiecture definition and process that enables IT to develop and deploy business capability rapidly. To the LOB-IT liaisons it means the governance, organization and the process for project/program management. For them SOA means defining the various business bulding blocks that could potentially be reused which shall help them reduce cost. And finally for the CIO - SOA is basically the IT Strategy for delivering business capability.

The Architect shall refer to vendor site such as BEA, IBM, Oracle, SAP, Microsoft, etc. for product informatiion and sites such as The Server Side, W3C, JavaSoft, OASIS, etc. for standards or technical information. The LOB-IT and CIO's would typically attend some CIO Forums or subscribe to some very specific journals, articles etc. made specifically for them by vendors or analysts.

Again - everyone is looking at SOA from their p…

Enterprise Reference Architecture

The above diagram illustrates the Enterprise Reference Architecture from an Enterprise Architect's (CTO's) point of view. An architect reviews the enterprise in layers starting from the network infrastructure layer all the way up to the business capabilities (proceses) and workbench (Portals) delivered to the business.

IT Architecture Matters! Services Oriented Architecture & Competitive Advantage

The following link is to my presentation at the Silicon Valley BEA User Group.

This presentation covers our first two generation of SOA adoption at BEA (IT). It does not cover the governance and organization details.