A rose by any other name would still smell sweet, just as a strategic corporate initiative is no more or less successful due to its use of certain en-vogue terms such as Enterprise Architecture (EA), Business Process Management (BPM), and Service Oriented Architecture (SOA). I was struck by the realities of the semantic terminology game that we play while attending the Open Group’s 17th Annual Enterprise Architecture Practitioners Conference in San Francisco last week.

There was a general consensus at the conference that there are common themes running throughout enterprises that have various labels attached. Those themes include the following:

• Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments. This become readily apparent as the SOA Governance panel (other panelists included Michael Nassar of IBM, Stephen Bennett of BEA, and Mats Gejnevall of Capgemini) that I participated in last Tuesday was quickly challenged by the audience to delineate between governing SOA and governing EA. The line between these disciplines is quickly blurring within many enterprises.

So what’s the take-away for us? We need to look past the labels that are applied and take a more business-focused and goal-oriented approach to education, mentoring, and ultimately solution development. We need to probe more intently with our clients to discover their strategic direction, business drivers, and objectives for one-year, two-year, and five-year timeframes. We may have the perfect service offering for them, but because it is labeled as SOA, BPM, or EA, it may not jive. I have several examples of this:

• Back in November, I wrote about Synovus, a mid-sized bank in the southeastern US, that spoke at SOAWorld in San Francisco. They were a non-traditional case study in that they did not set out to adopt SOA. They just knew that they had various business problems that needed to be solved. They set out to solve those problems and in the process created a SOA. If someone had approached them a year or two ago with an offer to enable their enterprise through SOA, they would have dismissed it because they were not doing ‘SOA’, at least not in name.
• Last year, a US Department of Defense (DOD) agency participated in one of my SOA governance workshops. Several of the students made the observation that although we had originally set out to talk about SOA governance, the vast majority of the concepts, principals and best practices that we discussed were applicable to EA. The mentoring engagement quickly broadened in scope and we began speaking in terms of governing the enterprise and aligning with business strategy. The principals, methodologies, and best practices all flowed very nicely into this broader scope. The ‘SOA’ label that we had begun with was immaterial to the objective — better governance of enterprise assets and business processes.
• Throughout last year Web Age Solutions worked with various clients that wanted to service orient their enterprise assets and orchestrate those assets as a part of executable business processes. Some of them called that SOA, others called that BPM. Some wanted us to describe SOA in the context of BPM and others wanted us to introduce BPM in the context of SOA. At the end of the day, the solution was the same. It was the same standards, same tools, and the training was about 90% the same. The difference was found in the labels attached and the emphasis upon certain key concepts.

It is imperative that we understand our client’s needs, perspectives, and bias with respect to trends and labels. At the end of the day, we are enabling them to solve business problems, not in order to check a box next to an acronym.

Top-down business process development and service orchestration is gaining increasing attention among the clients that we are working with. Their appetite for a more strategic end-to-end solution composed of underlying services is reaching a critical mass. Some are turning to formal process management strategies ala BPM. Others are taking a less formal, but still equally valid approach of simply managing process and service models and treating business processes and service orchestrations that execute within the context of a service bus or process engine.

One common characteristic that I have observed is the need for process champions. Each process needs an owner that can fight for it, protect it, and ensure that it remains relevant and value-added. Some organizations are tasking business analysts and business engineers with process ownership. Others are moving this responsibility further up to a senior manager or director. Some very progressive organizations are even defining a new breed of architect — The Process Architect. I had the pleasure of talking with someone from Ford Motor Company earlier this week and I was pleased to discover that they embrace this progressive perspective within their enterprise.

About a month ago, ZapThink interviewed me regarding the changing role of the business analyst within the service oriented enterprise. I took the opportunity to expand on some of these ideas in more depth. If you are interested, you can get the podcast from their site here: The Service Oriented Business Analyst

It’s been over a month since I’ve posted anything. For the past several weeks I’ve been heavily engaged with clients and several public speaking engagements related to Service Oriented Architecture (SOA), Business Process Management (BPM) and Enterprise Architecture (EA). A resounding theme as of late has been the importance of aligning the business and technology teams along shared enterprise goals. Although architecture and service design patterns are important, more and more enterprises are interested in the cross-functional synergy that SOA enables. In order to truly deliver upon the promise of agility that service orientation offers, it is critical that business and technology personnel work together.

So what exactly does this enterprise alignment look like?

• Cross-functional, enterprise teams must champion the adoption of SOA. Change agents and visionary champions need to understand and clearly communicate the SOA strategy to all levels of the organization. Technology-minded individuals and business-minded individuals need to be involved. This should also be a diverse, enterprise-wide initiative that has input from all lines of business. Some groups choose to establish or leverage an existing Center of Excellence, Competency Center, or similar objective group. Regardless of how formal or informal the team may be, the keys to success are passion, communication, and diversity.
• The Information Technology group must be treated as a strategic partner, not a cost of doing business. IT provides far more value than simply keeping an organization’s servers up and running. They are a key enabler of information and automated systems that allow humans to focus more on analytics and less on low-level details.
• Organizational transparency must be prioritized. The visibility of IT’s business value and internal capabilities must be raised to the business community (minus the technical jargon and useless acronyms). The business capabilities that IT has today and can reasonably make available in the future need to be clearly communicated to the business teams. Visibility is a two-way street though. The business teams need to clearly convey business drivers and relevant metrics so that the technology teams understand where the organization is headed.
• A process-centric approach to business. Business Analysts and Business Engineering teams are gaining increasing credibility within the modern enterprise. In order to truly bridge the gab between business and technology, it is essential for a common frame of reference to exist. Business process models offer a visual mechanism for both business and technology personnel to discuss, explore, and solve business problems without getting caught up in the details. Afterward, each team is then able to translate this into their world. The technology teams, in particular, have a lot of options available to them thanks to standards like Business Process Execution Language (BPEL) and Business Process Modeling Notation (BPMN). On the business-side of things, it is important that business processes become a pervasive element within the enterprise. Business processes should drive budget allocation, project management frameworks, and even human resource strategies.

Service Oriented Architecture has really grown to become an umbrella that encompasses an entire range of enterprise initiatives (service architecture, BPM, EA, governance, etc.). Rather than getting caught up in the technical ‘architecture’ aspect of SOA, I prefer to talk with clients in terms of business and technology alignment along service-oriented business processes. Service orientation is really a people problem more so than it is a technology problem.

As I explore this alignment concept further with clients, I will post some more on this subject. I might even distill my experiences into a white paper later this year. I’ve got a pretty full schedule this summer. If nothing else, I’ll be back in late June / early July to comment on SOAWorld 2007 in NYC.