I've been reading blogs and articles that define and redefine Service Oriented Architecture (SOA) and Business Process Management (BPM) as an approach that promotes better alignment of IT with ever-changing business needs, in a manner that increases organizational agility and efficiency and helps reduce IT costs. However, at times, I get surprised by the way business and IT react towards the concepts of SOA and BPM. Some spontaneous responses I get in conversations about SOA and BPM make me want to reiterate its underlying concept in the hope that it will help bust some myths.
“SOA” and “BPM” – these two three-letter acronyms remain among the most debatable IT terms. Though business and IT talk about the benefits of SOA and BPM, when it comes to real implementation everyone seems to consider SOA and BPM as good to have but difficult to get right. Because of this perception, SOA and BPM are slowly and gradually being dropped off the IT roadmap, especially in these difficult economic times.
Discussions also continue on the desirability of SOA for BPM. Though BPM can be taken as a separate initiative altogether, leveraging SOA helps with automating business professes in a modular manner. SOA's benefit here is that it integrates siloed applications and legacy systems and exposes IT functions and business operations as services.
In the current economic recession, some executives are questioning investments in SOA and BPM. But I would maintain that now is the right time to have a well-planned and executable implementation roadmap for SOA and BPM. I think that the need of the hour is to have SMART (Specific, Measurable, Accountable, Reliable, and Timely) SOA and BPM initiatives. Let me walk you through each SMART component and give you my reasons:
Specific:
The buzz is that SOA and BPM projects slip because they are too ambitious to be implemented. Do you really buy into that? I absolutely do not. When such initiatives fail, the reason is usually because the implementation occurs in isolation from business functions. SOA and BPM projects need to take into account the fundamentals of business operations, along with specific business drivers and needs. In other words, you need to tie SOA services into the business "services" and manage the business processes with the BPM discipline. The SOA and BPM approach is conceptually compatible with the agile/iterative approach (e.g., continuous integration), so having specific atomic targets and projects can reduce the risks associated with SOA initiatives and deliver value in rapid, small doses/ The impact on business accumulates in no time. The trick, of course, is to be intelligent about how you identify "services" and processes and to have a good understanding of their interrelationships.
Measurable:
In one of my recent assignments involving implementation of balanced scorecards, I came to appreciate that the more specific and measurable the objectives are, the more achievable the goal is. The case for SOA and BPM initiatives is similar: They need to be measured. But at times, the key performance indicators (KPIs) for measuring SOA and BPM tend to be technology-centric and measure only availability, capacity, etc. To be effective, though, you need to map the business goals to IT KPIs so that SOA and BPM initiatives can be aligned with the business, as well.
Accountable:
To ensure that you can effectively assess project execution and investment for SOA and BPM initiatives, you need to have the right governance programs in place and make your SOA and BPM initiatives need to be accountable to them. The assessments need to take into account the respective roles and responsibilities. Accuracy can be measured by how responsive your initiatives are when you need to realign processes to meet short- and long-term business needs as the business strategy changes.
Reliable:
SOA and BPM initiatives need to be reliable so that business processes can be securely shared with employees inside the company and with customers, partners, and vendors outside the company. With the increasing rate of mergers and acquisitions, service-level commitments need to be proactively analyzed for anomalies. This is also fundamental to the concept of "services." Each SOA and BPM component has to be independently secure, reliable and scalable enough to be used in a variety of ways in a variety of applications and/or as mashups.
Timely:
Time is an important parameter in deciding the future of SOA and BPM initiatives. In many cases, even if the projects are executed according to plan, the initiatives still hit the skids. By the time the projects are finalized, the business needs have changed. As a result, the organization feels as if it has taken one step ahead and two steps back. The conclusion to draw from this is that the focus should be on accelerating time-to-value and reducing time-to-market for SOA and BPM applications.
It seems to me that these S M A R T criteria are interrelated. For example, “specific” initiatives help in being “timely,” and being “measurable” and “accountable” lead to more “reliable” SOA and BPM initiatives, etc. To conclude: It’s the time to change the mindset of the believers who regard SOA and BPM as the silver bullet that will start providing business value from the very first day. So let’s start concentrating on what really matters.
I recall a situation in which a SOA-based payroll system failed because the designers ignored privacy requirements and relied too much on the consuming systems to provide role-based access. Do you have any experiences or thoughts you’d like to share about companies that invested in SOA and BPM and got desired business value? Or do you know about a situation where failing to consider the underlying principles actually had a negative impact on SOA and BPM initiatives? I’m eager to hear from you, so please add a comment. You can send me an e-mail message at juhi.talesara@advaiya.com.
Subscribe