BPMS

Reasons why SOA fails

Some days ago, a colleague of mine forwarded me an article titled Top 10 Reasons Why People are Making SOA Fail.

This article lists several points that must be considered in SOA initiatives. I really think they are very relevant, but the comments posted called my attention.

The major worries were about to explain SOA’s business value and the impact of organizational change.

It is a clear demonstration that SOA is being seen as a business issue instead of just an IT issue.

Questions that usually cause huge discussion, like vendors drive the architecture, was ignored. SOA governance, which is very important, was ignored too.

What I think could be analyzed more in-depth is the relationship between services and business functions.

I will discuss this issue on the next post.

SOA and Enterprise Architecture

Some definitions of Enterprise Architecture (EA).

1. Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.

2. An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization.

3. The EA is:
What: The structure of an Enterprise and its blueprint describing.
How: How the Enterprise operates and the processes executed by.
Whom: People.
Which: The technology implementing processes.
Where: Showing the location of people and technology.
Why: To streamline, align, blueprint, strategically plan, and confer agility.
When: According to the Enterprise transformation plan to a target state.

4. Enterprise architecture is an agency-wide framework for incorporating business processes, information flows, applications, and infrastructure to support agency goals.

5. Enterprise architecture is the organizing logic for business processes and IT infrastructure.

EA is about describing business and mapping businees to IT systems. It is about guaranteeing that the systems really implement what users need. EA describes which system is responsible for each information asset.

Having an Enterprise Architecture is a key factor to a successful SOA initiative. Analyzing Enterprise Architecture helps to identify required services for the SOA infrastructure.

Assigning responsibility for the services is part of SOA Governance. EA also helps to do this.

If a company does not have an enterprise architecture, it is very recommended embracing SOA and EA together.

Will ESB and BPMS from different vendors work well together?

Last week I was talking with a colleague about ESB and BPMS. Vendors are offering BPMS with ESB features, but the company where he works will evaluate BPMS and ESB separately.

I think it is hard to define where ESB’s responsability ends and BPMS’s responsability begins. Besides, what kind of requirement will guarantee that ESB and BPMS from different vendors work well together?

Standards could be used for ensure the interoperability of ESB with BPMS. But how to be sure the vendors really follow the standards? For example, if a requirement states that the ESB registry must be compliant with the UDDI Version 3 standard and another says BPMS must be able to discover services at an UDDI Version 3, when ESB and BPMS are from different vendors do you really believe they will always be compatible?

Choosing BPMS and ESB separately can bring the best of two worlds, but you must be careful to avoid a gap between the platforms.