It's often frustrating to bring a product or service to market before the market is ready to accept it. So I take solace when people with more influence start repeating what we say. It's great to see the analyst community catching up with the practitioners. I'm not sure I'm bought into "Business Capability Architecture" as a term, yet. I have misgivings about using 'Architecture' to describe a business function that is more aligned with Investment Advisor. But I'm not one to find a dark cloud in this silver lining. We've been deploying a capability-based approach to business architecture (TIMM) for the past several years now, formalizing it into a service offering two years ago. In talking with my peers, most of the large consultancies have adopted the language of capabilities. Given the success that we and others are seeing from this approach, it may very well be one of the most effective ways to manage complexity.

AAB

P.S. Trackback to original Forrester Blog post

For a while, we thought that SOA vs. BPM debate had been laid to rest. But as is the case with most theological disagreements, they never go away, they just hibernate. So after the latest round of strife, we updated our BPM+SOA pattern white paper ("Preserving IT Investments with SOA+BPM Coordination") and it's undergoing final edits. Here's a preview:

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.

Here is the link to download the full text.  Be forewarned, this is not a superficial assessment.

AAB

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.


AAB

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.

1. There is no 'standard' BPM message to sell the concept - and that's a good thing. BPM is not same for everyone. It will vary across verticals, across organizations, and even within organizations of sufficient scale. That leads to...

2. The most important determining factor of BPM effort success is stakeholder involvement. And that depends on knowing what will keep the stakeholders involved and committed throughout the initiative. Which means that while there should be a core message set to socialize BPM around the organization, there should also be a subset that is unique to each stakeholder. Without that commitment, and a point person at the executive level to continually refresh that commitment, success is unlikely to be sustained.

3. Another core part of sustainability is availability of BPM analysis resources. Several analysts and practitioners agreed that only 50% of 'classical' business analysts will be successful once trained in BPM practices. Many factors contribute to this, but the result is the same: plan accordingly, as reliance on BPMS vendors to provide this skill can lead to process models 'unique' (read: legacy) to vendor platform. Client/Vendor philosophy compatibility is an obvious key here, but assessing whether that compatibility is real before entering into a partnership is not trivial.

4. BPM by itself is not sufficient. There are other approaches out there (e.g. SOA, MDM et al) and they all have their strengths and weaknesses. Combining approaches tailored to solution is not trivial, but it is the optimal technology investment management strategy. Yet only 8% of organizations surveyed by Forrester link their BPM and MDM investments, and the pitched battle between BPM and SOA camps is well known. Talk about opportunity for improvement!

5. Thought leaders from other specialized process-driven disciplines, such as Records Management (RIM) and Governance Risk and Compliance (GRC), are now realizing that their flows are a special case of BPM. One of the corollaries of moving toward a disciplined selection approach (e.g. "Process First, Tools, Second") is that it gives organizations struggling with multiple platforms the ability to consolidate.

6. Successful BPM implementations take a holistic approach to the reforming process, supporting technologies, and supporting organizations, while breaking delivery groups into discrete chunks. The most effective way of determining what and how large those discrete chunks are? A capability-based approach.

AAB

Judging from recent musings on eliminating requirements in the world of LEAN, it appears that even this approach is not immune from bad requirements gathering and definition. LEAN techniques possess few tools to address this challenge - akin to one experiencing a stomach pain without understanding why it's there. Once the environment is optimized, bad requirements simply lead to optimization of bad solutions and related results. Very few actually look at optimizing the process of solution production - that is usually considered overhead - and even those who do still find that balancing optimization and assurance is not a trivial task.

What this underscores is that LEAN is just like other approaches, constrained by the same challenges that cause all projects to fail at a prodigious rate. This is not a surprise to the community that has been analyzing IT failures (Michael Krigsman, Roger Sessions, and myself included.) Our methods may vary and our disagreements may be good fodder, but the underlying problem statement is the same. And unlike individual thought silos, we actually have methods to diagnose why the subject is experiencing that pain in their belly. Would the likely answer include cutting the stomach out if that's where the pain is? Probably not, so eliminating requirements may not be a smart way forward.

AAB

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.