"The Bronze Horseman is a monument to Peter the Great from Catherine the Great. It stands on Senate Square, facing the Neva River and surrounded by the Admiralty, St Isaac's Cathedral and the Senate and Synod buildings. The statue, created by the famous French sculptor Etienne Maurice Falconet, depicts Peter the Great as a Roman hero on horseback, pointing the way for Russia, while his horse steps on a snake, which represents the enemies of Peter and his reforms."

What interests me in this statue, and why it makes an appearance in this post, is it's remarkable structure.  It is balanced on three very small points - 2 rear hooves and tail.  And being made of bronze, it is a very heavy statue.  It was impossible for Falconet to balance it just on the two rear hooves.  He needed a 3rd point to make it stable, and tail was that 3rd point.

Organizational structures are not all that different.  Where bronze statues have the force of gravity constantly pulling them down and other forces of nature slowly eroding them over time, organizations face many forces, both internal and external, that threaten their sustainability.  And yet, as I wrote in a prior post, most organizations seem to be missing that 3rd point of stability.  There are many internal groups whose purview is Organizational Persistence - both from a customer and organization points of view.  But most organizations have them scattered around with little budgetary or true oversight authority.  The thought of a third organizational branch was intriguing enough to merit several responses, and the conversation is still going strong.

One of the interesting corollaries is where would the Organizational Persistence branch report.  Ultimately, the group that is responsible for long-term viability is the owners - whether it's individuals, private equity, or shareholders.  In a case of publicly owned company, this group is represented by the Board of Directors. And yet, the shortcomings of BoDs have been well documented, perhaps most bitingly as by Carl Icahn's United Shareholders of America project.  But from a good governance perspective, that is precisely where the OP teams should be aligned with.  This alignment could benefit both sides - it could give OP teams the necessary operating room, while providing the BoDs the level of visibility required for operational intelligence.

AAB

Thanks again to the BPM/SOA Consortium for inviting me to speak at the OMG Technical Meeting in Jacksonville, FL on March 24th.  I've been compiling war stories and case studies on this topic over the past year - readers of this blog have seen some of them bubble up to the surface over several posts.  And during the last meeting in Long Beach, it struck me that those of us working on bridging operating models and approaches between Business and IT are missing a critical voice in the room - the voice of the P&L owner.  So for this presentation, I invited several P&L owners who have or are working with us to provide their perspective on what is right and wrong in their IT relationships.  Given how busy these folks are, most of them chose to share their stories as case studies, but some might just show up in Jacksonville with me!

Abstract: A lot has been written and said on the topic of Business/IT Alignment. A lot of methods have been tried, and yet the goal has never seemed as elusive as it does in today's business climate. Business comes to the table with the increased pressures of the business cycle, the ever increasing information velocity, and the ever-more demanding client. IT 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. Business comes to the table from the top down. IT 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 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. This presentation will examine Business IT Alignment Patterns (and anti-Patterns) from the perspective of Business P&L Owners at various sizes of organization.

AAB

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