Business IT/Alignment Anti-Patterns: Business Process is King

Tuesday, August 25, 2009 |

It is not surprising to see a lot of interest in aligning business and IT. In some cases, the relationship is so frayed that it could be fodder for entertainment news shows. As one business executive put it this week, "Dealing with IT is the worst part of my job." So as people grapple with approaches to repair these relationships, it's good to remember what we know doesn't work well. With that in mind, there is a wonderfully instructive case study about business process first approach to Business/IT alignment.
About 10 years ago, one insurance company went to town on process management. They defined all of their processes. They applied LEAN techniques. They re-engineered all of their technology stack to support these processes based on n-Tier architecture and BPM principles. The result was a tremendous platform that was fully aligned with business processes based on full alignment between business and IT.
This company reaped optimal benefits from this investment for all of few months - the market place changed. It wasn't a very large change, in the scheme of things, but it was a complete 180 degree turn in one of the fundamental assumptions made during process definition. Overnight, this company's sizable investment into state of the art technology became obsolete legacy - neither the processes nor the completely aligned technology stack could support this change. Of course, this became IT's fault for not being sufficiently 'business-aware'. Mind you, this really wasn't anyone's fault - there was no way to predict this change would occur, any more than you can predict what innovations will drive the market a year from now. So being process-savvy, the business introduced new processes to handle these new market rules. But because the system was fully aligned with the old process, it couldn't change that easily. And you couldn't just rip it apart and put it back together without impacting the existing book of business.
After much grumbling about IT's resistance to change and the vast barriers IT was telling them were required to make that simple change happen, the business cobbled together some access databases and excel spreadsheets and manual paper processes to augment the state of the art system. And as the book of business based on new market rules scaled past the ability of manual processes and other bubble gum and shoestring approaches to cope, business came to IT asking for help in automating their new process platform. As with most situations, the longer you wait the more it will cost. Shocked and awed by the new and increased price tag, business stakeholders decided to defer any technology investments and simply hire more people cheaper to run the manual processes. Thus they turned to Business Process Outsourcing (BPO) - which was wonderful for the duration of the first contract... We all know what happens after the first contract expires.
Business got into serious trouble in this case study by making what appeared to be sensible decisions about both short and long term needs. Their technology partners were also making what appeared to be sensible decisions about both short and long term needs. None of the decisions or intentions in this case are malicious, or even wrong - lots of people try to do it this way. But then lots of people believe that BPM failed them, too. To a degree, they are right - BPM by itself, without service oriented and data management underpinnings is very similar to what we used to do with COBOL on the mainframe a long time ago. In today's world, we call that legacy, and any business/IT alignment based on business process first approach will run into the sustainability challenge. Processes change too quickly for that alignment to stand the test of time.

As Promised: Capability-Based Analysis Transformation Paper

Sunday, August 16, 2009 |

It is ready. It is documented. Here are the cliff notes:

Using BPM, SOA, MDM, and Cloud Computing a small team was able to solve the problem of 'description' in a month. This solution was then used to automate IT Governance for a specific set of warfighting capabilities at the US Department of Defense. Now, this solution is being looked at for applicability across the large scale of capabilities within DoD.

My first response when reading the title: "That's a lot of acronyms/buzzwords in one sentence." Nonetheless, it's accurate. And it supports what I've seen as the next evolution of the disparate architectural styles - no one of them can actually deliver the promised benefits. It is the appropriate combination of these styles that enables that delivery. In other words, it's not "wow, SOA". It is "what can I do with the capabilities enabled by SOA?" In this case, it was "what can I do with the capabilities enabled by SOA, BPM, MDM, and Cloud Computing?" The first three were used to solve the problem at hand. The last one was used to do it at great speed.

Last, a bit about the problem of 'description'. Each discipline, whether business, technical, risk, project, organization, or (...) has its own unique perspective. Hence, people who have grown up in these disciplines are equipped with a set of tools that emphasizes certain strengths and at best ignores weaknesses. At worst, some of these tools purport to be able to solve world peace. Practitioners should (and sometimes, do) know better. So the way a business analyst describes a problem is different than how a technical architect would describe the very same problem. And that is different than how a security analyst, or a project manager would describe the very same problem. And of course, all of these dialects differ from how the actual customer describes that problem. The solution to this problem, then, would need to find a common language between the various disciplines and tranlsate their dialects in this language (yes, I'm talking about ontology without using the buzzword).

No, I did not suddenly lose my mind, or start using mind-altering pharmaceuticals. This has happened. This was done. And here is the link. Feel free to drop me a line if you have specific questions that could not have been addressed in the document.

Aleks

Are M&A Results Really So Poor?

Saturday, August 15, 2009 |

As promised, I'm blogging further on the topic of "Integration Capability Portfolio". One of the sources I'm relying on is a KPMG study from 2006 called "The Morning After." Collaborating with Doug on writing a reply to a research note from KPMG that was nothing more than an uninformed opinion made me wonder about the quality of any KPMG source.

On last business trip to New York, I was conveniently seated next to a gentleman who handles M&A transactions for GE Capital. Seizing on the opportunity, I asked him if the 65% disappointment rate passed his sniff test. He was surprised at the KPMG number - his experience was the reverse - 2/3 success rate. That only contributed to my paranoia about the validity of this source, and I'm doing research on finding other sources. Hence, I'd like to ask the readers to share their experiences and point me to other sources that either support or dispute this metric. Thanks in advance!

Aleks

Response to KPMG: Debunking the myth of SOA

Thursday, August 13, 2009 |

First off, let’s recognize that the KPMG article is an opinion piece that would have been much more helpful in 2003. There is at least one truth in the KPMG article - there is a need to cut through the SOA hype. However, it is a little ironic, that a large financial and risk consulting firm would make a perfect blanket statement such as “I’m yet to see many businesses extracting any real value from an SOA installation.” Perhaps the author, Jerry Iacouzzi, should have read CIO Magazine’s Winners of SOA Case Study Competition, a list of SOA-based projects and the real value they brought to organizations that completed them. Even if one hasn't had first-person experience with real value of SOA, that doesn't mean that SOA is all hype.

The article ends
by taking the debate up a level conceptually, What should actually be happening is that they [Business/IT] should be thinking more strategically about their IT architecture requirements or about the governance and control issues which arise from an SOA installation.” So if companies do that will their SOA investments suddenly produce value? Are there no other reasons to think about technology governance and control issues? What exactly are "IT architecture requirements"?

As silly as some of the article’s statements may be, what I really want to zero in on is the overall complaint
the author brings up. I think there is some validity there. But I have another interpretation about the source of the hype. It is not just that vendors and standards makers and large consulting firms have been pounding the SOA podium to get business. That’s natural and we should expect them to send that message. But, when I listen to the bevy of chants out there I often come away with the “Most services [SOA] are common across business units” or “SOA will break down business silos” messages. These messages suggest that SOA is a unifier of business operations, a re-arranger of business units into a monolithic company that is super-efficient. While such messages are true for some organizations it is not true for most. In fact, these messages are not sensitive to business operating models at all. They reek of IT adventurism.

There is a simple proof I can offer thanks to the work at MIT Sloan’s Jeanne W. Ross, Peter Weill and David Robertson. The work at MIT Sloan has identified four business operating models. Only one of them, called the unification model, behaves like the super-efficient uber monolithic organization that some in the SOA community seem to want to address. That same unification model lends itself to an enterprise view of infrastructure, service, and process simultaneously. But not all companies need such a grand unified vision to get value from SOA. In fact, most organizations don't need this grand unified vision to get value from SOA. Perhaps the lack of alignment between SOA hype and business operating model is what author, Jerry Iacouzzi, is reacting to in the first place, though that nuance is not discernible.

Dissecting the issues of SOA applicability run the gamut from departmental to business unit to enterprise. Which one are you? If your business units service different key customers and those customers do business with your diversified company for relatively unrelated product offerings, is there any need to optimize at the enterprise level beyond infrastructure? Optimizations for such a diversified company would yield most value at the business unit or even the departmental level. And such a ‘strategy’ would still produce benefits for the company, wouldn’t it?

So I think it’s important to realize that if we become frustrated with the ‘SOA hype’ that we should also take a deep look at our approach to SOA. Our frustration might just be another part of the ‘hype’ cycle.

How Much BPMN Do You Need?

Monday, August 10, 2009 |

I’m belatedly responding to Michael zur Muehlen’s post of the same name.

Though it is possible to dissect the research which Michael himself has put come caveats around I think such a dissection probably misses the main point which is that we all know, or should know by now, that business people want to excel at their jobs not at their modeling expertise. And the closer the IT position or IT role is to the business audience the simpler the modeling needs to be for that same audience. IT business analysts can routinely handle more than Michael’s “BPMN Common Core” but if the audience for their work cannot then doesn’t that limit your output from a practical point of view? At least during a JAD session? This is not to say that you could not refine your model after getting the appropriate approvals for your model concept. Of course you could always prescribe that the business subject matter experts take a course in BPMN. A few would take to it.

On the other side of the coin the closer one gets to process design and executable environments, as opposed to process analysis, the more precision you may need and therefore the more symbols you would need to represent process concepts and their related design patterns.

Perhaps our optimism is incurable that precision would permeate everyone who comes into contact with BPM modeling, BPMN modeling, or modeling in general. As a purist at heart I hear the call for more precision in IT modeling but I also know from experience that you cannot depend on everyone sharing that view or acting on the same desire much less force them to do so while you are trying to succeed in your modeling task. The upsurge in BPMN adoption enables a wide range of application and that is still a very good thing.

Value of Capability-Based Approach to Projects

|

While the "Capability-Based Analysis Transformation at the DoD" Case Study is in the final round of reviews, here's a little preview:

Initiatives that leverage a capability-based approach usually find that the application of capabilities delivered is more far reaching than initially anticipated. This is the reason why some initiatives, while appearing to disappoint by standard project management metrics, ultimately deliver more value through continued re-application of capabilities in assembling services and processes that may not (or could not) have been considered during the initial project. This case is no different...
Link will be posted as soon as all of the revisions are final!

Aleks

Are SOA-based Assets Really Reusable?

Sunday, August 9, 2009 |

Or are they just another color of legacy? After all, we as an industry have been promised the miracle benefits of Reuse many times over. So when Todd Biske started a discussion on his blog on the subject, I had to dust off the soap box:

Todd -

You're hitting the nail on the head here. The fundamental challenge is describing the portfolio of service assets in a succinct and 'grok'able way. Once an organization builds all this wonderful fully integrated best thing since sliced bread service portfolio, then what? Reuse is not a technical challenge, it's a challenge that requires organizational capabilities:
  1. Creating the appropriate translations to allow potential consumers to find what they are looking for in their language
  2. Creating the appropriate translations so potential consumers can properly leverage service assets
  3. Creating the appropriate incentives to spur adoption of service assets
  4. Integrating appropriate tools to allow all of this to occur in a scalable way
I think I just described the gist of what the "Capability-Based Analysis Transformation at the DoD" white paper / case study tackles. Reuse doesn't just happen, despite some of the more unrealistic expectations in the technical community!

Regards,

Aleks
Speaking of that white paper, it is in final editing round and will be available on the Technology Investment Management Library later this month.

Integration Capability Portfolio as Means of Competitive Advantage

Wednesday, August 5, 2009 |

That is the title of both the white paper that I'm working on and a presentation that I'll be giving at the SOA-Consortium Meeting in September. Here is the abstract:

What if you could integrate major mergers in weeks, rather than years? What if you could accurately forecast integration value, cost and timelines? Any organization armed with this set of core competencies would have a sizable competitive advantage in the marketplace. These questions are not meant to spur debate, nor are they academic. Processes and tools have progressed far enough over the past decade where building a capability portfolio focused on integration is no longer a state of the art. Assessing and improving the effectiveness of this capability portfolio is crucial to organizations who use M&A as part of their growth strategy and investment professionals who underwrite and finance these deals. This presentation will outline how capabilities enabled by Service Oriented Architecture (SOA), Business Process Management (BPM), and Master Data Management (MDM) can be assembled into an Integration Capability Portfolio that can be leveraged at any time, and with great velocity.

When I started writing this a few weeks ago, I completely underestimated the amount of thought integration required in order to cohesively tie the entire argument together. So, over the next month I'll be vetting some of the more controversial points here on the blog.

Aleks