Some adherents from the BPM community and some from the SOA community want to disprove each others’ software development approach and substitute their own. The noise levels escalate at conferences, on blogs, and perhaps into the office hall. While one may emphasize either BPM or SOA approaches on a project-by-project basis, it is very effective to use both approaches together for maximum resiliency and to preserve your investment in technology. This paper examines methodology details and architecture constraints for each, BPM and SOA, and compares and contrasts them, showing, in the final analysis, that they represent a natural fit that should not be avoided but embraced.
A while back, I posted a case study write-up that was instructive (hopefully) in dissuading organizations from aligning their business units with IT based on Business Process alone. Thanks to many discussions and posts and articles on the topic, it occurred to me that perhaps alignment is not what most approaches seek. Rather, one of the interesting sub-threads in many discussions around Business/IT alignment is the presumed need for Business/IT unity. That is an assumption that I haven't seen vetted all that much, and perhaps it’s a slogan that may be Orwellian at best. Dealing with both business and technology departments, our practice lives inside the ever-widening gap of understanding between the two communities - a gap continually widened by specialization. They each have their own business operating models, and they each have their pressures. The mismatch between the business operating models of IT and their business stakeholders (or BOMM for short) can provide clues as to why the relationship between business and IT sometimes comes to resemble a cold war.
Consider this: The business comes to the table with the increased pressures of the business cycle, the ever increasing information velocity, and the ever-more demanding client. The other comes to the table with solutions that seem to only increase in complexity bolstered by ever expanding technology disciplines, vendors, and standards, not to mention the baggage of years of suboptimal decisions coming home to roost. One comes to the table from the top down. The other from the bottom up. They each speak a myriad of different 'englishes'. They generally have an issue agreeing on how to define terms of engagement, or even who should own those terms, something we commonly see bubble up to the surface as data governance challenges.
The trouble is that there is a simple problem statement here, and it applies to both sides: lack of effective governance. Business people speak about the need for IT governance as way for business to control IT. IT people speak of various governance mechanisms as a way to reign in runaway business wants. Organizations should take a page from U.S. Constitution - there's a good reason to have multiple branches with oversight over each other. And what we're really missing is the 3rd branch.
So this is really a challenge to the risk management departments - audit, legal, compliance, program/portfolio management, security, privacy, enterprise architecture, et al. Some of them have a reporting relationship with Boards of Directors already. Some of them have influence on how IT budget gets spent already. And they each have their assessment methods. That is perhaps the crux of the problem: if these groups can't get their assessment methods to leverage each other’s strengths, the entire point is moot. Without an effective 'common criteria' like evaluation of both business and technology investments as a whole, effective governance becomes difficult at best.
I participated in virtual Business Process Management (BPM) conference on Twitter today led by several Forrester analysts. A lot of interesting insights came up (here's the link to the full transcript, and I'm sure the Forrester folks will be publishing something on the topic.) I'll just summarize what I took away and how it relates to running a successful BPM effort.
My statement today is that SOA’s definition greatly lacks a business context. Even the term itself, SOA, feels monolithic in its application as if once size fits all. While SOA yields services for business, the community of SOA proponents has not included a definition of SOA along business operating models but along the model of their own technical experience and insight.
I’m tired of hearing about SOA as something in singular form when business reality indicates that it takes many forms. And it’s not just that different organizations have different sized SOA projects or deploy SOA to support different customer facing situations. It is that business operating models can differ so much that their respective SOA naturally differs by equal measure.
That difference means that SOA strategy from one company to another would be unrecognizable.
Look at a company that has absorbed other companies over time. It probably has a set of business and technology silos to deal with. Depending on how many customers these silos share, SOA will look quite different to this company than to a company that has a large catalog of products that its customers choose from,,, meaning that the catalog company has a large set of similar customers while the company that requires silos to support its customers is quite diversified. If business units don’t share customers then they don’t share customer data either. And if you’re not sharing customer data then you don’t need to share services do you?
In a diversified company one of the things that business silos can share, since they don’t share customers, is the technology base: network, servers, security infrastructure, application platforms. The reason for sharing these “services” in a diversified company is to support a single business goal: Reduction of Cost of Goods Sold.
So in what way would SOA apply to such a company? At the enterprise level it would apply in the areas mentioned in the previous paragraph: network, servers, security infrastructure, and application platforms. But these aren’t generally regarded as business services. They are technical services. Possibly some shared and centralized services could be built around HR, Accounting, and Sales Reporting. But this would take business ownership of business architecture and a vision of reducing costs across an organization that is organically divided to support its customers, in other words, to do its business.
SOA can still be used within a business unit in the usual way proscribed by SOA proponents as long as customers within the business unit are shared by the different product groups; otherwise, the same pattern of diversification appears at the business unit level.
The takeaway here is this: there is an enterprise level of SOA and possibly a divisional level of SOA. the extent to which, services are shared within a division. The enterprise level of SOA depends on the business operating model and how diverse the model is. The less diverse the more sharing of services can occur.
If you are a proponent of SOA you need to understand the business operating model implications and constraints on your SOA.
About Capability Investment Management (CIM)
- ▼ February (6)
- ► 2009 (48)
Blogs We Follow
2 days ago
1 week ago
1 month ago
1 month ago
2 months ago
2 months ago
11 months ago
1 year ago
3 years ago
45 years ago