Agility is Sensible

Lack of Cloud Ready Apps is a Software Architecture Failure

2012-01-01T14:42:00.000-06:00

Seemingly a lifetime ago (2009!), I shared how security concerns have to be "baked into" any cloud platform, as well as a simple set of capabilities to consider when addressing said security concerns. Of course, information security is just one aspect of cloud readiness. There are others, and today's post from Chris Curran's CIO Dashboard made me ponder a couple of lessons learned from our cloud platform adventures of the past 2 years.

What I tweeted in response to Chris is that cloud-readiness comes down to a simple question: how robust is the middle tier of the system architecture? Specifically, how easy is it to integrate and how well instrumented is it? This can be problematic for most enterprise and SMB business applications. Very few of these were created with the forethought that both small and large grained chunks of functionality could ever be exposed as standalone applications themselves - outside of the safety of corporate networks. Add that integration and instrumentation are usually inadequate due to a combination of factors - project scoping/delays/failures, adoption of software design approaches that scorn architecture, and general lack of talent and experience at key positions - it is not surprising that Chris is advocating a comprehensive analysis of the total cost of moving to the cloud.

At the end of the day, lack of cloud readiness is a result of many factors and decisions that seemed sensible at the time to the decision makers. But we are where we are - and not being able to make a move to the cloud places organizations at a competitive disadvantage. That's not hot air - the difference between our platform using cloud-based services and not using cloud-based services is easily quantifiable. I can't expose the internal operating ratios, but that difference can be measured in several orders of magnitude in operational run rate.

There's been a movement in Enterprise Architecture circles to talk about the vast amounts of technical debt that have been accumulated over the years in most organizations. That technical debt grows with every decision that is made for expediency sake or with full ignorance (or worse, in spite) of supporting information. And while I haven't yet found many receptive audiences for the concept of technical debt, perhaps the hard numbers that force many IT organizations "out of business" over the next few years will finally convince the software architecture community of just how spectacularly they have failed at their job. And the total cost of moving internal applications to the cloud is just one of many quantifiable ways to measure that failure.

Emerging from Hibernation

2011-12-23T09:41:00.001-06:00

It's been 9 months since our last post. That doesn't mean that we're no longer here, or that we're not thinking about these topics, or that we don't have anything more to say - those of you who know me realize that option is just about impossible!

As some of you may know, we spent 2011 transitioning from technology management consulting to a startup incubator. That may sound strange - but the nice thing about having a comprehensive intellectual platform like CIMM is that is it allows for wholesale changes in business process with little impact.

We've embarked on several projects with CIMM as our key stone. Using Capability Based Business Architecture, we created a cloud-based business operating platform in 2011 that each of our projects can leverage to minimize their launch costs. And as some of these projects launch (congrats to Everybodysafe.com to winning the race to the starting line) we'll be bringing you lessons learned on using our platform to create businesses from scratch.

Observations on Capability Driven Management

2011-03-07T13:20:00.013-06:00

I'm finalizing my presentation for Business Ecology Initiative's Optimization for Innovation conference slated for March 22nd in Washington DC. Initially, I was approaching it as a humorous rejoinder on how to cope with taking the reigns of an organization one didn't have much knowledge of. But life has a funny way of throwing curveballs, so here are some thoughts that I'll be delving quite deeply into in 2 weeks:

As I hinted at a few weeks ago, investment into succession management programs - a laudable organizational investment into sustainable leadership - has evolved into a serious operational capability risk. While competing capabilities were always a possibility in our model, this is the first real example where investment into one has a negative impact on others.
I had the opportunity to listen to Dr. Jeanne Ross of MITSloan CISR a couple of weeks back. She made a lot of interesting points that will be expounded on in future posts, but the one that's relevant to the topic at hand came from a success story at PepsiCo. I'll paraphrase - as she interviewed the chief change protagonist, one of the off-the-cuff comments was that a major contributing factor to PepsiCo's success in creating their Optimized Core was stability at the executive sponsor ranks throughout the process. The quote was something along the lines of "I don't know what I would've done or would've happened if we didn't have that stability throughout the change process."
So that got me thinking. I've personally gone through an executive sponsor change as the "face" of a major change program. It's not an experience I'd like to repeat - nor have I heard of anyone in a similar position finding it a positive experience. So instead of looking at this topic from the viewpoint of the new boss, perhaps the real need is to prepare the people who are running these programs and operational units with tools to minimize the impact of this operational capability risk.

See you on the 22nd!

AAB

Enterprise Architecture is Misplaced and Other News from MIT Research

2011-02-18T14:36:00.000-06:00

Several interesting points that deserve their own blog posts, so this is just a conversation starter:

- EA should not be inside of IT, and it's usual placement hampers both IT and its effectiveness.
- EA maturity is directly related to organizational performance, and can be built in discrete stages.
- Overall IT Budget increases by a factor of 50% in organizations that are in Stage 4 (Business Modularity) and business leaders love that because they get more per use and time to market increases that give them competitive advantage.
- One of the determining factors of EA-lead transformation success is stability in the executive ranks (yes, my presentation on this coming in a month, so stay tuned)
- Strategic Agility has a dependency on evidence-based management culture. This culture cannot be built overnight, nor can it come from natural evolution. It has to be enabled from both top and middle.
- There are three (3) key requirements to work smarter: Operational Intelligence Backbone (Competing on Analytics), Business Rules Management (BRM), and Organizational Development.
- Align business activities with IT - not IT with the business activities. Otherwise you're trying to align the most static strategies with to the most dynamic. Create a core - and then align things to that core.

Please discuss!

AAB

Business Capability Naming and Content

2011-02-15T09:04:00.001-06:00

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.” WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.

Operational Capability Risk: Executive Rotation

2011-02-03T09:30:00.000-06:00

As announced last year, I will be presenting at the OMG Business Ecology Initiative's inaugural "Optimization for Innovation" Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit. As our team started researching for this presentation, we came up with a few statistics (yes, it's a tease) that even we didn't expect. Loss of executive sponsorship is almost always in the top 5 reasons for project failure. What surprised our team was the number of large organizations that actually have organizational efforts in place to make sure that executive rotations happen. While this makes sense from a leadership development point of view, it increases the Operational Capability Risk.

So the focus of the presentation shifted away from the executive point of view and toward that of an Operation or Change Programme leader. The majority of large scale organizational transformation efforts take time. Not just capital, resources, but time. Behavior cannot change overnight - it has to evolve little by little over time. It is just like the sport of curling, but without the stone thrower. The stone glides over the ice, and the most effective change agents simply sweep the ice around the stone with rather crude implements to guide that stone to where they want it to go. Forcing the stone any other way can be counterproductive, and just downright dangerous - it weighs a lot and there's very little friction to stop it from running over one's foot.

Sweeping takes time. Planned volatility in leadership throws a wrench into that need for time. If you are a change programme leader, planned leadership volatility means that you not only have to continuously communicate about your effort, you have to "sell" more than one executive to be that effort's sponsor. And to nobody's surprise, it is my belief that Capability Driven Approach is the optimal way to develop and deliver that sales pitch. Belief isn't enough in many books, though - so confirmation of many case studies and independent verification from Forrester Research helps as well.

AAB

Business Architecture and Business Ecology

2011-01-28T14:46:00.001-06:00

This is a response to a very thought-provoking discussion that's been going on at the Business Ecology Initiative LinkedIn Group on the topic of whether Business Architecture is synonymous with Business Ecology. I suppose the answer depends on where one draws the scope boundary around Business Architecture. Based on our observations from how this works in practice, it will probably be different in different organizations. For example, in our Vanilla Enterprise Architecture Capability Map, Business Architecture is a core business capability portfolio (or core function) of Enterprise Architecture, similar to how The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) positions the discipline. Business Ecology, on the other hand, encompasses Enterprise Architecture, along with other Office of the CXO strategy and planning functions, such as Risk Management, Portfolio Management, Asset Management, et al. It also includes the delivery and ongoing operational steady state functions of a given organization.

That's not to say that two are unrelated. The challenge for every organization is to find the "right" level of investment in the various core functions to balance short-term profitability with long-term competitive advantage. If one were to view each core function - whether strategy/planning, delivery, or operations - as a separate business unit, each of these core functions would have their own business architecture. Consider two core functions that most organizations of scale have (sometimes in spades) - Risk Management and Portfolio Management:

They each (RM and PM) have unique organizational attributes (e.g. culture, org structure, etc.), as one would expect of two organizations with completely different mission statements-especially around communication!
They each have unique business attributes - the business of mitigating risk is quite different than that of getting leadership to agree on the priorities of various efforts;
They each have unique technology needs and tools - although a seasoned Enterprise Architect may detect a certain amount of commonality between GRC and EPPM tools.

So in the example above, there are two core functions within the same organization, bound by the same organizational goals and objectives, empowered by the same leadership, with two competing missions, business operating models, organizational constraints, and technology. And that's just within the Office of the CXO. Once the analysis reaches the various business profit and loss centers, whose entire business operating models may be disparate, the natural result is complexity.

As I presented at BEI last year, complexity is nothing to be afraid of - it's just complicated (podcast here). Even in the simple example above, there is an optimal range of options that allow for the two competing core functions to work in harmony. Finding the range that works to align the given set of core functions is an obvious use case for business architects. The more core functions there are to align, the more complicated it gets, since there are quite a few dependencies (and personalities) to align.

Before I get too far down the rabbit hole, here's the gist: the business of Business Architecture is creating and managing the "right" equilibrium and range for Business Ecology - the alignment of all of the disparate business operating models and their core functions within a given organization. Not to say that it can't be done without a formal Business Architecture function. But the likelihood that it can be done consistently well diminishes as level of scale increases.

AAB

Capability Inventory Viewpoint Anti-Pattern, Part 2

2011-01-06T19:33:00.000-06:00

In a prior post, Doug was quite diplomatic in detailing why the Capability Inventory Viewpoint can become an anti-pattern. For those of you who've followed my insights over the years, I tend to be a bit more direct. I could dedicate a whole blog to psychoanalysis, but that's not why we're here. So in a typical direct fashion, here are some points that drive the Capability Inventory Viewpoint to become a Business Architecture Anti-Pattern:

Static - as Doug explained, the static nature can be bothersome. Let me take it further - just accumulating enough data to create an inventory viewpoint can be a major undertaking. In the project-based demands of many organizations, creation of this viewpoint can in itself be perceived as "success." Which means that project usually ends with little or no ongoing support for what is essentially a knowledge deliverable. That can (and usually does) lead to ...

Neglect - without the proper knowledge-worker staffing levels to continue updating the inventory, it can grow stale. Whether due to its static nature or lack of support, once created, there appears to be an inertia around the Capability Inventory Viewpoint. This is mainly due to ...

Omission - when capturing capabilities with the Capability Inventory Viewpoint as an end-goal, certain information tends to be left out. What's worse, as I wrote in 2010 when looking at the EA product market, even products that appeared to be ahead of their competitors were not ready for our consumption, because the Capability Inventory Viewpoint is really the only viewpoint available. So there are few, if any, facilities (outside of heavy meta-model customization that is anathema to most enterprise-scale clients) to capture and maintain things like capability dependencies, classification, and other portfolio attributes. Without these portfolio attributes, it is a Sisyphean task to properly valuate a capability vis-a-vis its peers, and communicate that value to appropriate stakeholders. That, indubitably leads to ...

Wrangling - initiative prioritization without capability portfolio information is difficult at best. There is no shortage of opinions that can come from every corner of the organization. Without the capability portfolio attributes to constrain these discussions, it is more likely that initiatives that are selected, and their order of execution, will not yield optimal results. Insufficient dependency identification has been a mainstay on every Top-10 project failure list since these lists emerged in mid-90's.

So if constraining the constant battle of opinions in your organization is of interest, my recommendation is to not allow yourself to be SNOW'd by the Capability Inventory Viewpoint!

AAB

Business Architecture Anti-Pattern: The Nature of the Inventory Viewpoint

2010-12-24T12:20:00.067-06:00

The Portfolio Viewpoint is a collection of well-defined capabilities and their relationships across a set of domains. The Portfolio Viewpoint supports executive level discussions and business strategy because it traces stakeholder (CEO, CIO, COO, CISO) vision to decision grade information for IT investment.

But the Portfolio View usually doesn’t start out that way.

It frequently begins life as an Inventory Viewpoint that has little value outside of Enterprise Architecture or Business Architecture teams. Some attributes of the Inventory Viewpoint are as follows:

As you can see the level of order is much higher and therefore of greater value in the Portfolio Viewpoint and while there are probably other attributes one can add to the mix the table above identifies some important ones.

The danger with the Inventory Viewpoint is that if it is maintained in the same condition long term then it becomes an anti-pattern. Collecting capabilities without understanding the depth of their connections and the wealth of their meaning will end up as shelf-ware in a repository, however sophisticated that repository may feel.

So resist the temptation to hoard capabilities. Don’t be afraid to talk to the business. And, above all, pay attention to what your stakeholders and their deputies tell you, particularly the office of the CEO, CIO, COO, and CISO.

Business Architecture without Capabilities?

2010-12-07T14:14:00.001-06:00

There's been a tremendous uptick of chatter about capabilities. At SenseAgility, we've been on the Capability Based track all along, so it's been fascinating to see how the market has evolved in a relatively short period of time. When I presented at Open Group Boston in July, I removed several background slides on Capabilities waiting for my speaking time slot. I usually spend at least 5-6 slides setting the context on this topic before getting to main points of my presentations. Fortunately, the first two speakers laid that educational groundwork for me, so my presentation became much more concise.

Concurrently, there's been a tremendous uptick of interest in Business Architecture. I don't believe these two developments of increased interest are orthogonal. If you look back just a year ago when we first published our Vanilla Enterprise Architecture Capability Map, neither one of these terms were common. Forrester had just came out in support of capabilities as a communication vehicle between business and IT. Business Architecture had just been tossed around by Gartner, Forrester, and a few independent analysts.

Given the relative immaturity of this space - we didn't even know what to call ourselves a mere 18 months ago - confusion is the order of the day. Business Architecture, as I mentioned in the Open Group Boston presentation, is being defined in various ways to suit what various interests are selling. Fortunately, those of us in management have developed a good "BS Filter" considering how much of it we have to wade through to make a decision. Capabilities are also being defined in various ways, but the trouble with these ways is that every single definition is correct. That is due to the fact, as Doug explained last year, that capabilities can be applied in every level of granularity. Hence, they're not the easiest creatures to understand.

So the question that I'd like to toss out is whether effective Business Architecture practice can be conducted without capabilities? Being so close to the fray, I'm not sure I have the objective context to answer this question myself!

AAB

The Language of Business

2010-11-23T07:55:00.000-06:00

IT has spent a lot of time and money chasing the “language of business,” trying to nail it down, trying to find a way to communicate with those who don’t want to know about computers or software or even why you have both of those things in the first place.

You’ve seen how the IT community has launched wave after wave of propositions that mostly make no sense to business leaders. Standards bodies that form around notations, training sessions, the analyst houses make proclamations about their proclamation strategy -- you have to say something.

But it is really a lot simpler than that in the final presentation. Its about time and money. You know, the thing that IT has used to try to learn the “language of business.”

The Startup Crash and Burn Cycle

2010-10-05T11:20:00.001-05:00

Entrepreneur: I have this great idea for a website. I know it’s going to make a ton of money.
Developer: I know [python, .NET, Java, Ruby]. I’ve done this before.
Entrepreneur: I can see that you have, great. Let’s get started.

The entrepreneur, trusting the developer, begins to feed him a couple of ideas. The developer asks questions whenever they get stumped. Weeks and/or months later, behold, a website arises!

But this is not the happy ending – it’s only the beginning. Now the fun part begins.

Because when the entrepreneur gets close to some potential enterprise customers and they ask about such mundane concerns as security, integration and website customization. Uh, what? Worse, they want monitoring and tracking – as does the entrepreneur since he needs reporting on a per/customer basis to understand sales and site usage.

Only the developers have since checked out – either physically or mentally. They weren’t interested in maintaining the site. Their brilliance is only appropriate to building the site. Too bad they never did any maintenance programming, ever. If they could have seen the brilliance of others their effort may have been the better for it.

Now what? It’s unusual for developers to document well in such circumstances, and the entrepreneur doesn’t read [python, .NET, Java, Ruby], nor is he particularly interested in learning how to read them. Of course he could hire someone who does but then he knows how that turned out.

On the plus side, what the entrepreneur has, is a demo capable website. He can sell it. And, with luck, it’s a stepping stone to something that will stand up to the heavy traffic required to make a “ton of money.”

The problem is that without an analysis of client needs against the strength of the code he doesn’t know. Even if all is well, he knows he has to take a step back to take two forward.

But all is not well - even a cursory analysis shows that the code is not rationalized on the back end - because there is no back end. All the code is in the equivalent asp/jsp server, meaning that, in the end, testing costs will be much higher for changes than is sustainable. All the website text is embedded in the code which equals the need for changes and that there’s no way to easily customize the site to each customer’s content requests. There’s no service or facility to upload large data sets for the corporate customer. There’s no separation between the primitive reporting interface and the operational data store meaning that every time the entrepreneur wants a report it will impact his site’s performance. Oh, and tokens representing sign-on are sent in the clear, and that’s the extent of the security framework. This, in turn, limits the entrepreneur’s top line revenue possibilities, as larger and more established companies require these issues to be addressed prior to considering a purchase or licensing agreements.

At SenseAgility we’ve seen this pattern over and over. It’s not necessarily wrong – it is even encouraged by the Private Equity community who is more interested in a smaller up-front investment than long-term viability. The entrepreneur does have a functional website that he can sell and that might even support a few customers. But by this time, they have usually invested several hundred thousand dollars into what is essentially a throwaway. Was it worth the investment?

You decide.

What Business Architecture and Pudding Have in Common

2010-09-07T09:37:00.000-05:00

(this is a response to the recent article in Architecture and Governance Magazine titled ‘Archimate: Adding Value to TOGAF’ - registration required.)

I was walking down the hall last week when the VP of Finance stopped me and asked me for my latest BPMN and Archimate diagrams for the “X” project that was going to revamp the marketing campaign software. He wanted the diagrams on his desk as soon as possible. If this sounds likely then you and I have probably had different work experiences, not to mention career paths.

I would suggest that the vignette in the previous paragraph is as likely as finding a shovel in Louis XV’s ballroom. So why is it that the good folks at TOGAF and Archimate keep trotting out Archimate viewpoints for EA and Business Architecture?

My answer would be that they’re fascinated by the tools of proof. These tools like Archimate, BPMN, UML are some of my favorite tools. But really, to expect others to have the same enthusiasm is unrealistic.

The business people that I know just don’t care about the actual diagrams although they might be interested in the proof or at least the fact that I have some proof in my pocket somewhere. I’m talking here about the sponsors, the people with the ultimate financial authority, the P&L owners, the ones sponsoring the business architecture (strategy) assignment.

If you’re thinking, “they should be interested” or that “we’ll educate them regarding our super great notation so that we can communicate” then I have to suggest you’ve missed the mark already.

No, the folks I know just want verify that I understand their issues. How I talk to them is critical because they listen to me repeat back to them my own understanding prior to the presentation of strategy options. I do use models behind the scenes to verify my understanding and to provide a backbone to my strategic chat but I talk to the operational people to acquire that understanding. By the way, the operational people are interested in the proof side of the equation but they aren’t the ones making the investment decision.

So the tools of proof are half the story? Well, actually they represent 80% of the work in business architecture. They just don’t show up in the strategy part of the presentation. Actually they don’t show up in the presentation at all, period. But if the tools of proof occupy 80% of the strategy analysis maybe that’s why architecture centric organizations like to call their tools “Business Architecture”. But that is doing what the recruiters do -- everything is business architecture to that crowd.

My advice is to make an adjustment where notations are concerned. Keep the details in the background and not the foreground and if you’re selling Business Architecture don’t talk about the tools of proof to your sponsor unless they ask.

To learn more about keeping the proof in the pudding see our Capability Based Business Architecture curriculum here.

Will Business Architecture Replace EPfMO?

2010-09-01T12:25:00.000-05:00

Original question was precipitated by an exchange with Brian Sondergaard (@bsodberg):

aleksb6 hmm.. if #bizarch's major responsibility is to manage the org's biz operating model(s), is bizarch next evolution of change mgmt? #entarch

bsonderg @aleksb6 if you're conducting a poll... "Yes"

aleksb6 @bsonderg not a poll, per se, but... there's an assumption that #bizarch and #pfmo must work together; what if #bizarch replaces #pfmo? #cio

Our assumption at SenseAgility has been an emphatic "No, they should work together inside of a strategic planning office, e.g. Office of the CIO." This is a view espoused by a lot of people in the EA community (including, now, Gartner EA analysts), so it's not exactly controversial:

pallega @aleksb6 #pfmo is a consumer of #entarch. They're richer together. #bizarch is a viewpoint of #entarch http://tinyurl.com/35j5amm #cio

aleksb6 @pallega #entarch and #pfmo as pillars of ofc of #cio/#ceo has been our assumption too; but there's enough crossover to question that

pallega @aleksb6 #pfmo, #pmo, #governance, #metrics, #finance & more are richer when consuming EA advice - does the #cio see it that way? Not always

But what if we're wrong? One of the things I alluded to in my twittersation with Phil is that there is a significant crossover between the capabilities of Business Architecture and Portfolio Management. For one, both must produce a roadmap. They are both trying to achieve Business/IT Alignment. They both have a vested interest in the organizations standard planning and delivery methods. And both have a vested interest in collection and measurement of metrics from both operations and projects. There is plenty of potential for friction between the two organizations - they both play in the same arena, yet often report to different people. So, should there be two separate organizations, or will Business Architecture replace Enterprise Portfolio Management in its current form?

AAB

Focus of Enterprise Architecture?

2010-08-31T08:04:00.024-05:00

We put our marker on what the focus of Enterprise Architecture should be a a year ago this week with the release of our vanilla EA Capability Map. Skip a year forward, and the conversation still rages as hotly as it did then. Perhaps it's not surprising that the vanilla EA Capability Map post, even though it's a year old, is still the most read post on our blog. So as we celebrate its first birthday, here is an interesting illustration that still makes that post relevant today:

RSessions Thinking in terms of a new paradigm for EA: Simple As Possible Architectures (SAPA).

aleksb6 @RSessions the common perception of #entarch is that it's too heavy; so with Simple As Possible Architectures, would EA even exist?

RSessions @aleksb6 EA would have a more tightly focused vision.

aleksb6 @RSessions can you elaborate what "more tightly focused vision" for #entarch would look like?

RSessions @aleksb6 One completely focused on the issue of SAPA (Simple as Possible Architectures.)

aleksb6 @RSessions how would that be implemented? how do major responsibilities of #entarch change from where they are now?

RSessions @aleksb6 EA would no longer focus on improving business or improving IT, but on ensuring solutions are SAPA.

I was with Roger right up until that last tweet. In my experience, Enterprise Architecture groups that don't focus on improving business or IT capabilities cannot justify their existence in medium to long term. Tackling complexity of our environments is something that we should do, but certainly not to the exclusion of stakeholder driven concerns. This is where a Capability Map is useful, if nothing else, as a sanity check. Tying EA processes and services to the Capability Target Diagram ensures the correctness of EA itself, so it doesn't focus on one concern to the detriment of others.

AAB

You Want Me To Run What?!

2010-08-27T16:05:00.003-05:00

Thanks to the folks at OMG Business Ecology and especially Brenda Michelson, attendees at the inaugural "Optimization for Innovation" Conference in December will be treated to a very handy guide on how to manage organizations (and their buried messes) that executives inherit on a regular basis.

Title: "You Want Me To Run What?!"

Abstract:

Change in the New Normal is different from the change we used to expect. Once upon a time change came from the outside. Now, quickly changing leadership has introduced a new stress on management and companies as they try to cope. Rarely will a director spend more than 2 years on a rotation with the same unit. While this allows for a more rapid leadership development, it exposes day-to-day operations and in-flight improvement projects to elevated levels of risk, especially during transition periods. It is no surprise that loss of stakeholder support has consistently been a top 5 reason for project failure.

Hence, the key question facing today's business leaders is how to efficiently evaluate and understand the capabilities of their new organization to minimize these risks. This session will provide a foundation for constructing and evaluating capability portfolios to both optimize ongoing business operations and minimize the exposure during transition periods. This management approach will equip the audience with a method to produce an actionable and measurable 30/60/90 day plan they can implement within their organizations.

What the attendees will learn:

1. Why capabilities?

2. Quantifying capability risk

3. Using capability-based approach to quickly assess a new unit

4. Scaling capability-based assessment from single team to entire organizations

Target Audience:

C-Level Executives, their directors, and Profit and Loss owners.

We will see you in Santa Clara!

Of EAs and MBAs

2010-08-22T11:36:00.000-05:00

While we've been busy with our Entrepreneurial program over the past couple of weeks, it doesn't mean that we haven't been monitoring the topics du jour. One of the more interesting threads being bounced around on Twitter is whether Enterprise Architects should have MBA training. This thread started rather innocuously by the noted EA twitteratti Todd Biske:

"Should Enterprise Architects have/get an MBA?"

As is the case with such a philosophical point, it will have its adherents and detractors (here's a good primer from Mike Kavis). Full disclosure - I'm a strong proponent of EA and MBA, for both communities, and not just because I've been armed with an MBA during my entire stint in Enterprise Architecture.

THE responsibility of, and often the biggest hurdle to, successful enterprise architect is to be a trusted advisor to both business divisions and IT divisions. That means being able to speak many languages - that of the business strategy, business operations, metrics (including financials), technology strategy, and technology operations - in multiple areas of both business and technology, which often have their own dialects. Without either formal education in business administration or a significant amount of time on the ground managing business strategy and operations, I have a hard time seeing an an enterprise architect appearing credible when discussing these topics.

This doesn't mean that people without MBA can't work in Enterprise Architecture, in fact actuarial background is just as good, if not better, than an MBA when it comes to understanding financials. Nor does it imply that an MBA automatically allows someone unqualified with technology to be successful as enterprise architect. At the end of the day, an EA must be credible as master of many trades, so I don't really see how an MBA would hurt that credibility.

AAB

Microsoft's Take on Enterprise Architecture

2010-08-21T08:47:00.000-05:00

Normally, we don't pay much attention to Microsoft when it comes to the areas of strategy and planning, but this is just too interesting to pass up. Gabriel Morgan of Microsoft posted his lessons learned from a year of leading Enterprise Architecture team entitled "A Breakthrough: Maturing EA to be a Catalyst to transform the Company" That's generated quite a bit of buzz - quite a bit of it ambivalent (see Tom Graves' take here for more thoughts on this topic.) So I'll go a different direction, and analyze the impact of what Gabriel's team has been at Microsoft on their target client base.

A bit of history. Everyone knows that Microsoft has been trying to carve out a significant share of Enterprise IT spending. With major competitors, such as IBM and Oracle (among others), already well entrenched in this space, it's not been smooth sailing for the folks from Redmond. So while many a smaller company run on Microsoft foundation, penetration at higher end of organizational scale has been largely limited to departmental success stories. The further Microsoft products become entrenched in smaller scale organizations, the better the Microsoft's enterprise division targets these clients, the more difficult it becomes to sell Enterprise Architecture. Why? Because at the lower end of organizational scale, Enterprise Architecture happens informally. Most organizations in that position simply don't have the necessary capital to invest on internally-focused process improvements while delivering on their operational commitments.

I have worked in the EA doing vertical for a long time, so while I might wonder at titling what Gabriel's team has done at Microsoft a "Breakthrough," from viewpoint of his team, it's nothing short of an evolutionary jump. If successful, Microsoft will be moving away from the developer-first culture that has been at its core for as long as I can remember to a discipline based culture. What will be interesting to see is whether the kind of discipline EA brings to an organization will translate into better products and more discipline among its small to medium customer base.

AAB

Evolution

2010-07-27T23:56:00.000-05:00

You’re all familiar with the knuckle-dragging pre-human to bipedal homo sapiens series of silhouettes that looks like it first appeared in National Geographic (anyone remember?). But this time I’m using them to illustrate some of the major points on the upward curve of software evolution.

And while neither human evolution nor software advances in correctness are as linear or as easily charted as the graphic suggests there is a similarity between them where highlights from a particular tree become visible from a single point in time, like now and to me.

Starting with Structured Programming - this was a breakthrough in code maintainability where similar logic or logic related to similar data was modularized for easier understandability. Without such an approach if/then/else clauses spanned many pages, making a code base nearly impossible to debug in a timely manner much less to hand off to another developer.

Objects overcame the division between separating code by logic or by data by allowing the developer to combine them both into an object, a single entity.

While this was a revolution to those in the craft of writing code it only helped those writing code to understand their world better and outsiders were not usually part of the arrangement of objects, class diagrams and activity diagrams notwithstanding.

Services and processes were the first entities (in this tree) to be of concern outside the development community. They could be thought of as directly supporting the business. They could be socialized and discussed by subject matter experts and process owners. Although services could be placed in repositories and called by other services and SOAP vs. REST could be argued by the technology community these were sub-plots to what was going on. And what was going on? Software usage was mushrooming and becoming a management problem that wouldn’t go away.

In other words, software was experiencing catastrophic success.

In the late 90s and early 2000s the DoD came upon the concept of capability. Each branch seemed to have its own take on how to utilize the concept and in the current DoDAF capabilities have their place in the DoDAF meta-model.

I’m here to tell you that the story doesn’t stop there. While having a meta-model is critical to keeping your feet on the ground there’s a lot more to capabilities than that.

In short, we at SenseAgility Group, are offering a Capability Based Business Architecture course that draws its inspiration from such things as IEEE 1471, MIT Sloan’s Business Operating Model, UML, BPMN, Archimate, & TOGAF. This means that we provide, through a succinct capability lens, a way to connect architecture with business architecture on a cost and value basis. Not only that but we can connect process, organization and risk/security issues in the same way.

This allows management at any level to organize software and invest in it according to their strategic plan or even to develop a strategic plan using capability based analysis. That last idea, btw, is what the Capability Portfolio is all about.

DPT

Live Blogging from OpenGroup Boston - Jeanne Ross

2010-07-20T07:39:00.007-05:00

Up first: Jeanne Ross of MITSloan School of Business on Evolving EA from IT to Business

note: I've been following her research since publication of "Enterprise Architecture As Strategy", since I've witnessed first-hand the consequences of Business Operating Model Mismatch (or BOMM for short). Not surprisingly, there are many posts on this blog that discuss Business Operating Models and their impact to organizational vitality and stability.

"Architecture is a tough topic at a typical cocktail party."

"Architecture problems are not IT problems."

Why Architecture Matters:

Enterprise Architecture: the organizing logic for business process, data, and IT capabilities reflecting the integration and standardization requirements of the firm's operating model.
Agility: the use of existing IT and business process capabilities to rapidly generate new business value while limiting costs and risks.
Many firms are not in a position to concern themselves with agility

Keeping the firm out of trouble (risks and costs)
Making the firm more competitive (NFP: more effective)

Architecture function cannot drive benefits if everyone isn't on board

Key question: how can Architects sitting in IT get everyone in the business on board?

Going through the research on "EA as Strategy" and "IT Savvy"

My question on the maturity graph - the y axis supposedly measures "Strategic Business Value." What is the definition of "Strategic Business Value?" What are the components? How can the points on this curve be quantified? If Enterprise Architecture starts marketing to the business on the value of maturing from silos to business modularity, or points in between, these numbers will be needed to create a compelling and organizational context specific business case.

"Four Stages of business maturity - silos, local standardization, optimized core, and business modularity, and symptoms/capabilities of each

Commitment to IT:

- Strategic Choice Making - how will we use IT (and more importantly, what is the scope of IT)?
- Actionable Assessment - How will we keep on track?
- Working Smarter - How will we work digitally?
- Distinctive Digitization - What digital capabilities will we create & reuse"

Going through 7-11 Japan, Toyota Europe, and Campbells Soup examples.

@bmichelson's take: "#entarch is is mmm mmm good"

To end:

"If there are no business metrics, there is no business architecture. Stop the train!"

Could not agree more. This is why we include Metrics and Measurement capability as part of the Business Perspective in our Enterprise Architecture Capability Map.

Entrepreneur, Prepare! (or Beware)

2010-07-06T15:34:00.000-05:00

I've had a few insights after helping businesses launch as we have over the past year. First of these is about preparation. When our clients talk to financing sources (Banks, VCs, Angels), one of the first comments is invariably about how well prepared they are. It seems counterintuitive, and even strange, but it is apparently the majority that ask for money without being prepared and by that I mean a fully baked business plan, long and short term financials, and proposed valuations, etc. That is suboptimal on multiple fronts -

Not preparing for investors and lenders lengthens the vetting process. This is a common complaint on both sides of the deal, and is likely the most common cause of value loss in these transactions.
Then, there are few investors and lenders that won't automatically default to categorizing such request as coming from a "unserious" person. From their point of view, there are really no mulligans for how busy the requestor is - there are many requests, and all they can assess is data in front of them.
If process moves forward, not understanding proposed valuation puts the requestor in a very vulnerable position. To be sure, even CAPM is not a trivial calculation, much less Arbitrage based methods. However, this is where the investing party can demand a much larger equity stake of the company than they should be entitled to based on cash flow projections, discount factors, and risk. Without knowing the "base" from which to negotiate from makes for a difficult negotiation.

My philosophy in business has always been colored by Sun Tzu: "The general who wins the battle makes many calculations in his temple before the battle is fought." That's not to say that we need to spend an inordinate amount of time in preparation - this is where Capability Based Approaches help. As one of our clients noted recently, "it's like strapping a jet engine to my idea."

AAB

Capability Investment Management Revolution

2010-07-06T12:14:00.000-05:00

Back in the early 1900s a concept called "Modern Management Practices" or "Self-Control" was all the rage. Originally conceived at DuPont and General Motors it was a way for managers to have detailed control over employee tasks - because back then managers actually knew everything there was to know about the production line. Essentially, it was a process automation approach. And it worked for over 50 years, until machine-based automation wasn't enough for competitive advantage. Computers entered the work environment and we have been trying to figure how to cope with information automation and management ever since.

So from the 1950s on, several management models have attempted to harmonize information management with process management. The first of these was Deming's Total Quality Management (TQM). It was greeted with such skepticism that he had to go to Japan to try it in practice. Drucker followed with "Management By Objectives" (MBO) in late 50s, which was essentially a rehash of Self-Control with a twist - rather than managing by task, the approach allowed for some creativity and knowledge to be used by giving employees objectives and letting them come up with optimal way to satisfy those objectives.

The 1980s brought a slew of management approaches. Porter's "Strategic Management", a revival of TQM based on Deming's success with Japanese industries, and Cooper, Johnson, and Kaplan's "Activity Based Costing" (ABC). The1990s brought Hammer, Davenport, and Short's "Business Process Reengineering" (BPR) plus Kaplan and Norton's "Balanced Scorecard".

All of these approaches, save Porter's "Strategic Management," are focused on how things get done. Most of them allow for a feedback loop for strategic decision making, but that's hardly enough for consistent practices in identifying, developing and defending their Sustainable Competitive Advantage (SCA) - the purpose of Porter's work. Everyone provides ideas on strategic management, but inherently omits "how" information processing affects strategic decisions. To be fair, this is consistent with a deterministic view of management, where causality rules the day. And yet, if there's anything information processing has shown us in the past 50 years, it is that business is not deterministic. Hence, entering the 21st century where velocity of information is approaching the speed of light and coherence of that information is questionable, correlating information to make the appropriate decisions has never been more challenging. We see the effects of this in how often projects fail to deliver to expectations and continuous turmoil in strategy and planning functions like Enterprise Architecture and Portfolio Management.

So while the main challenge for Capability Based Management is to provide a consistent method for correlating diverse data to increase fidelity of information used in decision making, it will have an uphill climb without breaking the deterministic view of management that is so built into our business management school curricula.

Decoding Business/IT Unity - The Podcast

2010-07-06T06:43:00.000-05:00

Great many thanks to the team at OMG for getting my Decoding Business/IT Unity Presentation through production and posting the podcast last week! Listening to what I said 3 months ago and correlating it with a new book I just finished has given me a few new insights - a lot of which will be appearing on this blog over the next few months. Special teaser on theme: Complexity is an Illusion.

AAB

Interesting Discussions on LinkedIn (EA Network Group)

2010-06-04T08:00:00.000-05:00

Yes, you need a LinkedIn Account. And yes, you have to be a member of Enterprise Architecture Network. But those two prerequisites are not very difficult to obtain. Meanwhile, there are a couple of very interesting discussions going on - interesting enough for me to comment:

"How Can We Effectively Measure Enterprise Architecture?" started by Wayne Kurtz

My take:

...the set of possible measurements for EA is very large. This is partially because EA is glue - whether between strategy/execution, or business/IT, or IT/IT, or whatever pairing thought leaders in this group may conjure up next. And partially, it's because there are two very different questions:

1. "I'm mostly looking for how we measure the effectiveness of EA as a discipline."

2. "How do EA practitioners, and their clients/constituents, know if an EA effort is succeeding or not. "

The metrics required to answer these questions are very different, so I'll tackle them in order.

First, is there such a thing as EA discipline? I'm aware of many EA disciplines. As Phil Allega of Gartner recently quipped on Twitter, "Low barriers to entry="roll" a framework from others or from scratch." Even approaches that mascarade as standards (e.g. TOGAF ADM) require so much customization for relevance that each organization will end up with it's own TOGAF-based EA (if successful, that is.) So the only metrics that wind up making sense here are how "LEAN" is your EA without losing effectiveness - e.g. the cost effectiveness of organization's EA Capability Portfolio. These range from Advocacy Curve measurements (how many people are actually doing what your EA is influencing them to do, and how well) to regular old operational and HR metrics for the EA team as a unit.

Second question can be just as complex in practice. In our Capability Based Business Architecture seminar, we call it the Eye of the Stakeholder. EA is an enabling function - hence, success criteria for successful EA organizations are improvements in KPIs for their stakeholders. Complexity is inherent in negotiating how to please many masters, and quantifying their contentment quotient in hard currency.

and

In what ways do you partition your architecture, and why? started by Tom Graves

My take:

As (I think) you've seen parts of this approach already, we partition an organization's architecture in the following way:

Capability Portfolios contain

Capabilities that contain

Services, Processes supported by

Technology partitioned into

Client Side, Presentation, Business Logic, Integration, and Data Tiers arranged by

Internal/Secured/External Network zones containing

Business Applications, Infrastructure Applications, Platform, and Network layers

Several classification types possible in each layer, so classification framework is unique to each organization. It's what most people refer to as "customizing" an EA framework of your choice (TOGAF, Zachman, DoDAF all are equally fit for this purpose). Pertinent components at each layer of the cake are used to assemble solutions that adjust to business strategy changes. Effectiveness of said solutions to adjustments is measured by KPIs. At least that's my vision of how organization value can be attributed to EA.

TOGAF and TIMM

2010-05-26T11:30:00.007-05:00

The Open Group committee made a conscious choice to encourage customization of TOGAF, since every organizational context is unique. After all, TOGAF is a framework, not something you swallow whole to get well. If you look at the first BPMN sub-process below, “Select Reference Models, Viewpoints, and Tools” from Part II - ADM Phase B: Business Architecture, you can see that customization is built right into the process steps themselves.

(See the text in TOGAF-->Part II - ADM-->Phase B: Business Architecture-->Steps.)
The above diagram is not unreasonable but notice there are no roles defined for any of the tasks or sub-processes. You’re supposed to define the roles yourself earlier in Phase A: Architecture Vision.

Also consider these additional customizations in TOGAF:

You’ll need to connect viewpoints, although they’re catalogued in another section, to specific stakeholders. And maybe the viewpoints listed aren’t for you. TOGAF says that it is not a complete list and that you’ll need to customize these for your purposes.
You’ll need to define artifacts required by you and your stakeholders for each phase. Again artifacts are catalogued by phase but you’ll need to accept or reject them for your purposes. In SenseAgility’s TIMM we’ve invented new ones and new uses for existing diagram types.
Diagrams and artifacts have text explanations but no sample views, even the ones that might be graphical. You’ll have to experiment with these approaches.
Deliverable samples are nearly non-existent although Stakeholder Management and Business Scenarios and a few others are fairly covered.

So if you’re feeling some disconnectedness with the TOGAF approach you might need to realize that some work is required to fill in your customized version of TOGAF. Our customized version of TOGAF is TIMM and our Capability Based Business Architecture seminar covers TOGAF Phase B: Business Architecture.

EA's Big Missing

2010-05-18T09:24:00.000-05:00

Enterprise Architecture (EA) organizations across the country have been hammered. As if the severe recession wasn’t enough, there are other reasons to account for this. Here are a few:

EA organizations are notoriously unable to prove value.
EA frameworks do not yet help EA organizations to prove value.
EA tool vendors generally don’t help EA organizations to prove value.

Unfortunately the climate in the EA community is still inwardly focused on IT issues and not outwardly towards client concerns. That’s another reason EA doesn’t receive funding.

As we've seen lately in our review of TROUX, value for capabilities is missing but costs aren't. How can you show value in such a situation? And that’s not rhetorical. With or without a tool, if your EA organization itemizes costs without linking them to value provided, then the only thing they can show is that EA activities are a drain on the corporate treasury. That's not to say that there is no value to EA - and probably not what the EA team wants to communicate.

EA’s and EA leaders need to focus on a cost benefit analysis (CBA) of their capabilities. A CBA is part of your critical path - all the more so if your CIO reports to the CFO.

All is not lost if you haven’t come to this conclusion already. But start now to improve your EA image on a value basis.

Buzzword Central

2010-05-17T16:59:00.004-05:00

I'm looking into AgilePoint BPM Suite for a client. I haven't heard much about this particular tool good or bad, but since this client is not small - nor are they interested in getting smaller - I want to make sure that whatever "plumbing" they decide on can support their current and future scale.

When I ran across this graphic on the vendor site, I was overwhelmed by the sheer number of buzzwords on the picture without any semblance of what it all meant, except to say that it's metadata driven. Really?! Is there a non-metadata driven BPMS?! Are you kidding me?! A list of questions suddenly arose. Where is rules management? How about BPMN support? Or XPDL? Or BPEL? If folks at AgilePoint are interested, I'll be glad to help them build a professional diagram for their site.

EA Tools Matter - Just Not That Much!

2010-05-15T14:55:00.002-05:00

After spending some time critiquing new release from Troux Technologies, I received a lot of inquiries about other tools. Since SenseAgility has a vibrant Enterprise Architecture practice, I've dealt with a lot of these tools either through evaluation or implementation - perhaps even all of the ones listed in Gartner MQ and Forrester Wave. But we're not Gartner or Forrester - so the critique was from the point of whether the new improvements in Troux make our life easier - (and you can read below that they don't, and least not yet.)

Here are some of the queries I've received:

"What do you think about IBM's System Architect?"
"Why don't you like Alfabet's PlanningIT EA Tool? Is there something better?"

The answer is simple - every single one of these tools work. Whether they will be successful in your environment is another question, and one that analysts won't be able to answer during your 30 minute call. And the single greatest determinant of success is not whether it's IBM, or Alfabet, or Troux, or any other vendor. They all have their strengths and weaknesses, and they all have their own meta-models. They all have widgets, whether Flex or .NET based, and they all have standard reports to delight most technical architects.

Those are important, but not as important as whether your EA group has an Architecture Blueprint Method that's been agreed upon by all of their stakeholders - a way to consistently model overall system architecture at all levels of OSI stack, from network through application. If your EA group has one, then it is more likely that EA tool implementation will yield a positive ROI (project success can never be taken for granted.) If your organization does not have an ABM in place, don't worry about which tool to purchase. Investing in any of them will likely result in a waste of time and treasure.

AAB

Troux Technologies introduces TOGAF 9 ADM Support

2010-05-13T10:49:00.004-05:00

No, this is not a free promo for Troux. I did have an opportunity to listen in on the release conference call/presentation and this is my impression.

The Good:

Full TOGAF 9 ADM

This is important for any Enterprise Architecture (EA) group that will be leveraging some portions of TOGAF. Let's face it, nobody should even attempt to use all of TOGAF, but at least the capability to do so is in the product.

Flex-based widgets

Yes, I like them despite Steve Jobs' personal crusade against Flash. Proposals are proposals, but give me something that works now.

Support for Capabilities

Obviously, I'm all over this since there are no tools on the market that explicitly support our primary analysis techniques. This is an important step in the right direction, though as I'll explain below, it's only step 1 of many more.

Modernization Roadmap Options View

I single this widget out because of its potential impact. Anyone who's had the privilege of creating PowerPoint presentations with roadmap options will find this feature extremely useful.

Collectors for CMDB information

Alleviates that master data management headache.

The Bad:

Custom notation

I know the icons look a lot nicer than standard Archimate set. But to anyone who doesn't know the tool, this is a barrier to productivity. So wouldn't it be nice if it were the standard Archimate set? Especially since Archimate is also owned by the Open Group.

Out of the Box Spaghetti

Standard views of the architecture are simply scary. This tool seems to have been created with a single stakeholder viewpoint in mind - that of the technical architect. This, however, restricts a lot of its generated graphics from being utilized as presentation material out of the box.

Capabilities are NOT about Cost!

Since this is our primary analysis technique, a lot of comments here.
It appears that Troux product team has read what Forrester, Gartner, and SenseAgility have been saying about capability-based analysis, but didn't quite understand why they are valuable - in a word, value. Capabilities in Troux are all about cost management, when in reality, they are about value management. If a CIO comes to the table with a list of costs of capabilities without pairing them to value delivery (e.g. KPIs), they shouldn't complain that they are being managed as a cost center.
There didn't seem to be an intuitive way to create capability dependencies. It looked like the product team took available presentations of capability swim lanes (mine among them) without realizing that dependency lines are usually removed for presentation purposes. Oh well.
Still waiting on response on how to create capability portfolios, if that is at all possible.

The Ugly:

There are 3 main issues that Troux product team should consider for future releases:

Capability-based analyses tools seem incomplete, which makes it worse than not being there.
Troux Accelerator packs were mentioned, but without a localized Architecture Blueprint Method, populating and keeping the Troux Metaverse in synch with reality on a timely basis is difficult.
It's nice to see CMDB integration, but what about Process repositories? Rules? GL? It'd be nice to see more focus on master data management when applied to knowledge repositories.

Summary:

Good next step that keeps Troux ahead of competition, but still far from a full EA platform.

Why Cloud-Sourcing is Here

2010-05-11T08:21:00.000-05:00

Consider two projects with similar business and technical capabilities delivered:

Online analytics and business intelligence portal built with standard BI development and off-shoring practices. From initiation to end, 9 months and $1.4mm, on time, and +/-5% of budget - a successful project.
Online analytics and business intelligence portal built with cloud-based BI provider, using "expensive" on-shore development team. Same methodology, 3 months and $500k - quite a bit ahead of schedule and budget.

I'm a skeptic by nature, so I tend to wait out the hype. And when it comes to Information Technology, the amount of hype generated can only be bested by the entertainment industry. Early last year, I took a wait and see approach for "cloud" since it was generating a lot of hype. But then, these two projects occurred back to back. Once you get past the hype, there are significant cost savings and time to market gains that cannot be denied. In a sense, cloud-sourcing showed me the money, and fast.

That's not to say that all is wonderful in going to the Cloud. Several of respondents that I interviewed for the "Diagnosis: Cloud-Aware Applications as Competitive Advantage" presentation were very blunt about challenges of migrating existing applications and existing application development methods into this brave new world. Both methodologies and design principles have to be tailored (and then followed and measured rigorously) to allow for an effective cloud-aware application. However, with cost effectiveness and time to market opportunities inherent in creating effective cloud-aware applications, it is certainly an investment worth making.

AAB

Of Metrics Programs and Governance Capabilities

2010-05-07T07:35:00.000-05:00

Over on TWDI, Wayne Eckerson has a very thought provoking post on "12 Characteristics of Effective Metrics." And while all 12 are important, the one that caught my eye as fraught with the more difficult challenges is 'game proofing'. Here is Wayne's definition:

Organizations need to test all performance metrics to ensure that workers can’t circumvent them out of laziness or greed or go through the motions to make a red light turn green without making substantive changes. “Users always look for loopholes in your metrics,” says one BI manager. To prevent users from “fudging” customer satisfaction numbers, one company hires a market research firm to audit customer surveys.

Seven deadly sins indeed, or as OMG calls it, the Business Motivation Model. Understanding capabilities being measured gives the Metrics and Measurement groups (e.g. IT Effectiveness, Office of CIO, Office of CFO, etc.) ability to create a program with governance capabilities built in to insure against such gaming. Importance of using capability-based approach here cannot be understated - if organizations can't trust their metrics to reflect reality, the value of their Governance, Risk and Compliance (GRC) investments will be severely diminished.

AAB

A Brief Review of BA approaches: IBM's RJ10451

2010-04-17T14:48:00.000-05:00

IBM’s RJ10451 was published in August of 2009. Titled, A Comparative Review of Business Architecture, it is well structured and thorough, using parameters that are reasonable and not specific to any business domain and therefore generic.

That the article includes notations such BPMN, Archimate and meta-model type standards such as OMG's BMM and BAWG surely means the space is nascent. However, we can all use the article’s structure to think about how we're focusing our own BA. Is your approach strategy? Operations? Business Network focused? Revenue & Performance Model centric?

Also part of the article’s structure is what each approach says about and defines and markets the following:
        •        Conceptual Model
        •        Methodology
        •        Tools
        •        Service Focus

As of this writing the only part that SenseAgility lacks is a comprehensive single tool. All but one of our execution models is based on standards that any UML/Archimate tool can provide. Of course we also use spreadsheets and presentation software.

As far as the article itself...

McDavid's Business Concepts class model is a good example of how a class model can be used to describe a BA domain. SenseAgility’s is considerably more complex as well as more detailed but McDavids was created in 1996 and not 2009-2010.

IBM's Component Business Model is typically heavy but contains generic business capabilities that could be used to populate a generic SenseAgility BA capability map.

Interestingly, out of the four BA domains Strategy & Structure, Business Network (customer/supplier), Operations and Revenue & Performance Model, the one least covered by any of the existing BA approaches is Revenue and Performance Model. This is where SenseAgility's approach shines. Our CBA’s link directly to capabilities and provide input to our Road Map deliverable.

Happy sailing.

What Business Architecture is Not

2010-04-08T17:55:00.000-05:00

There’s a rising crescendo of chatter about business architecture lately, so much so, that recruiters have caught on and are starting to bastardize the term to attract all manner of talent to their open positions.

Of course there’s a long list of what Business Architecture is not. It is not technical architecture but you knew that right? But did you know that it is not BPM or ETL or SOA? Nor is it setting business goals for your company. Business Architecture is not Enterprise Architecture as it is currently practiced or as it is currently allowed to practice in some companies (don’t talk to the business).

Business Architecture is not about only one thing. You can’t gain skill in a tool and therefore have the ability perform Business Architecture. You can’t even necessarily perform the function of Business Architecture if you’re a successful Enterprise Architect. You might have a better chance or you might not. Being multi-disciplinary means being able to think on many levels and in many domains simultaneously.

Like Enterprise Architecture and business it is multi-disciplinary. It has to be because successful Business Architecture ties things together. The things it ties together are things like Business Processes, Organizational structure and tasks, Technical Architecture and Risk Management.

Now you may be thinking that if you’re a requirements analyst that you’re doing Business Architecture. Good thought but that’s not quite it. As a requirements analyst you’d be analyzing requirements for a particular aspect of a technology decision that’s already been made. Business Architecture comes before those decisions are made and in fact it helps people (executives) make those decisions.

In short, Business Architecture informs decision makers about the complex road that lies ahead and in that take on Business Architecture is implicit the ability to provide relative valuations on the specializations that the organization has or that that organization needs in order to fulfill its goals. So yeah, you need technical chops, process awareness, an understanding of how organizational function can be broken down and the importance of risk management and security in those decisions, and, oh yeah, you need to link all that to business objectives and business goals (which are not the same by the way).

DPT

Value of Operational Intelligence

2010-03-30T21:20:00.000-05:00

Traditionally, Business Intelligence (BI) has focused on looking at historical data and trying to understand patterns of behavior via a variety of approaches. Organizations have spent untold billions implementing both vended and home-grown platforms to aggregate data, mine it, and provide some sort of reporting capabilities for decision support purposes. These efforts have proven to be no different from other major initiatives - sometimes successful, most of the time less so. Rather than focus on success/failure metrics, I want to focus on something more basic - are traditional approaches to business intelligence enough in today's environment?

Two factors stand out (there may be more) - information velocity and customer experience. When it comes to information velocity, people are now bombarded with data. Correlating that data into actionable information is becoming more challenging by the day. This has a measurable impact on the business cycle, so time to market has become critical - especially with response capabilities. For instance, if a car manufacturer can't accurately gauge customer, competition, and regulatory response to a widespread issue - or even gauge what the issue is and how widespread it is, the results can be devastating to brand equity and even survival of the organization.

So a lot of organizations are coming to a realization that improving customer experience should be a key objective. In quantifying this objective, customer experience metrics are in large part dependent on level of engagement - both positive and negative. Organizations that look to the past to gain insight into this level of engagement are behind the eight ball - even if you find a correctable event (or worse, a series of events), the amount of time that transpired between the incident(s) and your ability to respond can reduce the effectiveness of your response. And that is if the organization already has the right business capabilities in place to respond immediately. Worst case scenario, these capabilities don't exist, and management decides to ignore or cover up these incidents because risk and cost of building the response capabilities outweighs the short term benefits. With increased information velocity, both of these tactics are becoming untenable.

What this suggests is that events themselves have intrinsic value, since they can be thought of incident/response pairs for business capabilities. Nor is this value binary - the event value gradient is bound by how quickly an organization can respond to it - similar to risk management. The longer the period between the event occurrence (or incident) and event response, the less value is realized (or more risk is taken on) by the organization. Yet, the vast majority of data management and aggregation methods (even today) rely on T+n (where n is number of days, weeks, or months after event occurs when data is aggregated) approaches. Clearly, this can become an insurmountable challenge to executive decision support, which begs a question - why are organizations still investing in these methods, when Operational Intelligence methods are both more effective and cheaper?

Decoding Business/IT Unity 2

2010-03-30T11:38:00.001-05:00

Thanks again to the Business Ecology Initiative and BPM/SOA Consortium for giving me a collaborative platform to discuss this very important topic. After a great discussion in response to the "Decoding Business/IT Unity" presentation, and I look forward to hearing how it sounds on the podcast. Here are some of the more salient (and perhaps controversial) thoughts:

Expecting to address a major challenge with one tool is naive at best. There are many tools, experts, and adherents. And yet, the symptoms of project failure have not improved dramatically in almost a decade.
Complexity is Complicated. It is non-linearly dependent on Depth of Context - such as number of people, organizations, stakeholders, viewpoints, etc. involved.
Complexity cannot be eliminated - as long as there is context (e.g. there are people involved.)
Complexity is, however, manageable with capability-based approaches, because they integrate a number of approaches to address the challenge at hand.
So Business / IT Unity is a very specific point of the Business / IT Alignment gradient that is only possible with very shallow Depth of Context.
And finally, Business / IT Alignment is not just an IT problem. It takes two to tango.

AAB

Are Current Organizational Structures Inherently Unstable?

2010-03-12T22:20:00.000-06:00

"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

Decoding Business/IT Unity

2010-03-02T07:47:00.001-06:00

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

Business Capability Architecture?!

2010-02-22T10:22:00.006-06:00

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

Preserving IT Investments with SOA+BPM Coordination

2010-02-18T17:57:00.002-06:00

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

Business/IT Alignment Anti-Pattern 2: The Myth of Unity

2010-02-13T10:04:00.007-06:00

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

Six Notes on BPM Jam

2010-02-10T19:13:00.010-06:00

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

RIP Requirements. Long Live Requirements!

2010-02-08T07:17:00.014-06:00

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

SOA Manifesto and SOA Definition

2010-02-01T11:12:00.001-06:00

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.

The SOA Manifesto is to a business perspective as...

2010-01-28T09:54:00.002-06:00

The SOA Manifesto published in 2009 contains a few references to SOA’s importance to business. If we take the idea of “business value“ or business related directives within the SOA Manifesto part of the SOA Manifesto as opposed to the Guiding Principles part of the SOA Manifesto we see that about 3 out of 9 statements relate to the business. Specifically, we have words like ”sustainable business value,“ ”Business Value“, and ”Strategic Goals“ in this section.

The Guiding Principles section repeats the same pattern of emphasis where the following lines may qualify as business related:

Identify services through collaboration with business and technology stakeholders.
Verify that services satisfy business requirements and goals.
Evolve services and their organization in response to real use.

I realize that this 3 out of 14 record may not convince you that SOA practitioners are serious about business alignment despite their insistence to the contrary but this is probably better than it was before they made their statement. Even if the SOA Manifesto is weak business-wise it was probably necessary to say it and we can thank the signatories for their hard work.

Now we can move on as a community. Now that we have some agreement on SOA as a platform of thought maybe we can apply the same patterns that services bring to technology to other areas such as organization, risk, and business. Then we can also tackle the myth of a monolithic SOA definition.

The Business of Manifestos

2010-01-26T11:04:00.001-06:00

My short and brief research on manifestos started with my reading of the SOA Manifesto published in 2009. I have a couple of responses, one about the need for manifestos in software related causes and the SOA Manifesto in particular.

Let’s start with what I consider the comical side of software manifestos. In general manifestos first applied to political statements, serious political statements about what the authors considered life and death issues. Witness the short list below:

Manifesto of the Communist Party
Unabomber Manifesto

There’s also the Chipotle Mexican Grill Manifesto here.

Their juxtaposition certainly stretches the idea of what a manifesto is and who can use that particular form of expression. Like the term ‘Whitepaper’ it has taken a spectacular popularization of purpose.

Here are some links to software manifestos.

GNU Operating System Manifesto
Manifesto for Agile Software Development

The need for a SOA Manifesto is rationally explained by Thomas Erl here. But despite his reasonableness and the lucid principles expressed in the SOA Manifesto how can such a proclamation help business, P&L owners, understand the need for SOA? If SOA is for business then its primary expression should be directed to business leaders in business terms, no?

Does a SOA manifesto help here?

Business Operating Model of IT (Part 2)

2010-01-20T08:25:00.012-06:00

In the last post of 2009, I asked business leaders how they can be proactive in assuring that their technology leadership is properly aligned and delivering the decision-grade information they need to make the optimal technology investments. Several of them replied in private, so I'll paraphrase these conversations (along with some very interesting tweets) in this post. In today's world of Information Technology, the question of Business/IT Alignment seems to be asked by lines of business struggling to understand optimal use of technology while, at the same time, the IT departments struggling to justify necessary budget levels, seem obsessed by the issue. In reality, it takes two to tango. Perhaps, if we start with a presumption that IT does indeed have a business model that is sufficiently differentiated from a line of business operating model, perhaps we can shine a bit more light on the subject.
In "Enterprise Architecture as Strategy", Jeanne Ross et al lay out the notion of Business Operating Model. This is not new to regular readers of this blog - we've been exploring this concept and its implications for quite a while! They also provide the four common models - Diversified, Unified, Replicated, and Coordinated. They then provide a set of rough Business/Technology alignment constraints with what they call "Enterprise Architecture States." What's interesting to note is that Business Operating Model types can be applied to the IT Department as well as the business under which they operate. We can see these operating model types in IT Departments regardless of size, type, and vertical. For instance, in a diversified model, separate IT departments will run separate networks, separate mail servers, separate shared drives, separate everything. And yet, if Enterprise Architecture States can be properly applied in this context, it suggests that IT Business Operating Model can be assessed and assured via these states just like any other line of business Operating Model.

As I noted in my last post, our capability models illustrate that there are two inherently competing business models within IT - run the lights (don't rock the boat) and technology as competitive advantage (invent new boats or move the boat around). I see this conflict in the formation and dissolution of Enterprise Architecture, Portfolio Management, Business Architecture and other efforts that collectively define the "Office of the CIO" - a regular occurrence in most large organizations. Some of this is certainly due to a dearth of qualified resources, an issue that several groups (e.g. CAEAP, PMI) are trying to address. However, most of these organizational changes occur within technology groups. So perhaps a lot of this upheaval is due to the inherent conflict between the “run the lights” and “technology as competitive advantage” perspectives? Regardless of root cause, this internal IT fracture regularly contributes to IT/Business misalignment rather than alignment.

Another source of IT organization instability comes from a lack of segregation of duties, a violation of one of the enduring models for organizational stability. A technology organization responsible for both perspectives, governance and execution, will be inherently unstable, and therefore unable to sustainably align with the Business, because the priorities are not just competing - they are polar opposites. This point has not gone unnoticed by others. Chris Curran's concept of IT Czar that sits outside of IT is just the latest in this chain of thought. The flurry of thought activity around Running IT as a Line of Business (RITLAB here, here, and here) on both sides of the debate is also contributing to the conversation. But while the technology management thought leaders argue about the concept, here's the reality on the ground: as our Technology Investment Management practice has evolved, several new engagements follow the model of our technology investment managers reporting directly to the business leaders responsible for profit and loss. Besides being good business practice for our clients, this seems to strike the right organizational alignment cord with my risk management experience: oversight is rarely effective when those who are overseen are conducting it.

AAB

Value of Enterprise Architecture in a Diversified Business Operating Model

2010-01-10T09:30:00.004-06:00

This question came to me from Bala Somasundaram via LinkedIn, and is being reposted with author's permission

Aleks,

Read your blog post on Business Operating Model mismatch during M&A and how EA/Capabilities can help iron out some of the persistent problems.

I wanted to discuss with you on other point. As mentioned in the book EA as Strategy book, some of the models - for e.g. - Diversified - models are able to grow inorganically by making mergers/acquisitions - especially large ones. They are clearly profitable and clearly growing year-on-year. But, they dont necessarily do EA-led planning or treat IT as their competitive advantage. [Am sure many leading businesses/CEOs dont treat IT as their partners, instead a utility].

In the book, authors have mentioned that such companies would rely on their pure 'management' capabilities rather than architecture capabilities.

So, what do you think, from your perspective that would make a case for EA in such operating models?

There are two parts to the answer - first, when we released our Enterprise Architecture Capability Map into the wild, one of the accompanying caveats was that maturity of each capability would be dependent on several factors, including Business Operating Model (both as-is and to-be.) Second part of the answer is done in a roundabout through application of Appropriate Use for Enterprise Architecture - full EA is of limited value in such context, however, parts of what EA should be responsible for can be leveraged for competitive advantage as detailed in my Object Management Group presentation.

AAB

The Business of Information Technology (Part 1)

2009-12-26T11:16:00.011-06:00

As a difficult 2009 comes to an end and a brighter 2010 dawns, organizations that have weathered the storms must now re-factor more objectives than just short-term survival into their plans. Prior to the tumultuous fall of 2008, one of the more common objectives for Information Technology departments was to "run IT as a business." Many interpretations of this objective exist, but by far the most common and familiar to anyone who spent any time in organizations whose business is non-technology oriented is the following statement:

"We're not in business of technology, we're in business to ... fill in primary business focus here ..."

This mantra has become a standard slogan for IT leaders to show they are in tune with the business imperatives. Business and IT alignment, however, has proven itself to be a challenge that's not easily solved with a slogan. And what if the slogan itself is wrong? After all, it's not common to hear heads of HR or Legal, or any other enabling business unit, to apply this slogan to their focus - as in, "don't worry about the legal ramifications, we're just trying to sell ..." or "don't worry about following standards in preparing our statements..." In every other profession, it is rarely presumed that professional standards can be relaxed if that professional is working for an organization that is not providing those professional services. Information Technology is not quite as mature as law or accounting, but if it's not a profession, then what is it?

As we compile capability maps for various business models and operating models, the cross section of capability maps for Information Technology has a very interesting story to tell. Effective alignment of Business and Technology objectives requires a certain formality of Business and Technology Architectures as organizational scale increases. That formality, in turn, provides a glimpse into basic building blocks of IT. Turns out that the business of IT is to advise their business partners on their technology options (both pro's and con's) and then deliver on the technology options their business partners in a way that does not preclude future business needs from being effectively satisfied. One might summarize the business of IT as a technology advice and delivery organization - directly opposite to the mantra quoted in the beginning of this post.

With several new disruptors to business as usual for technology already here (e.g. Cloud Computing and growth of alternate usage platforms) and on the horizon (e.g. nanotechnology, quantum computing,) business leaders can no longer afford their technology leaders to be anything but a trusted partner. Days of IT as order taker only have been waning since 1990's, but the pace of change and comparative competitive advantage that can be gained with appropriate adoption of new technology paradigms have made it completely obsolete. The question now is not what technology leaders need to do to show value. The real question is how can business leaders be proactive in assuring that their technology leadership is properly aligned and delivering the decision-grade information they need to make the optimal technology investments?

It starts with the first question to ask any prospective CIO or CTO: "What is the business of IT?"

AAB

Will Cloud Computing evolve the role of CIO?

2009-12-08T11:28:00.005-06:00

Interesting idea surfaced yesterday during the OMG's Business Ecology Initiative (and reinforced by today's session on SOA, BPM and Cloud). As the industry is moving into an age of choice in computing platforms, the role of Information Technology as a business unit may be changing as well. Rather than building custom applications as a norm, the focus may become integration of SaaS, PaaS, and IaaS offerings in the cloud. This is not a traditional IT operating model - it more resembles a system integrator operating model. And hence the surfacing of the idea that every CIO should have a strategy to address the General Contractor of Cloud services.

This has tremendous implications (as Todd Biske already tweeted) on service-centricity of technology departments - success seems unlikely without these capabilities as part of IT Core. It also has an interesting corollary to integration (or LEANing) of business process of IT. A fully functional Office of CIO becomes a necessity, and not a nice to have.

AAB

November Poll Results

2009-12-01T06:05:00.003-06:00

For the month of November, we asked our readers,

"What best describes perception of Enterprise Architecture in Your Organization?"

Direct Enabler of Profitability - 0 votes
Starting to Prove Their Mettle - 10%
Helpful in Spots - 20%
Annoying (but necessary) bottleneck - 40%
The Knights to Say "No!" - 20%
EA is Valuable? - 10%

Obviously, we have quite a bit of Enterprise Architects as readers! December poll will be based on direct quotes that we've heard from our practice clients during annual planning. Stay tuned!

AAB

What is Successful SOA?

2009-11-30T11:24:00.005-06:00

It's a timely topic given all the interest lately in measuring the value of SOA. After all, success or failure in a given organization is utterly dependent on adoption - whether by stealth of by fiat. So timely, that I ran across an interesting poll around SOA Governance in LinkedIn Groups that I'm reposting with the link:

Which of the following elements essential for successful SOA?

a) Service Management and Governance

b) SOA Reference Architecture

c) SOA Maturity Model

d) Service Registry
Be a part of our survey: http://bit.ly/2H8W1X

The real answer, of course, is all of the above, and none of the above. SOA is not about SOA governance, regardless of what vendors in that space will have you believe. Governance is just a management approach to ensure that SOA investments to become too complex. SOA is a disciplined approach to building technology capabilities, so while the options given in the poll are useful, they are not a necessity. Even with all of the technical capabilities in place, SOA adoption may fail (and has in several instances). Without modification to the business, organizational and risk mitigation capabilities (depending on Business Operating Model) technology itself is a money pit. In case of SOA, or any other large scale change program, success is unlikely through 'if you build it they will come' approach. Chances are, if you build it, and the organization is not ready for it, nobody will show up to your SOA party.

AAB

Why Reference Architecture(s)? (Part 2)

2009-11-23T18:51:00.005-06:00

The first post elicited quite a few great comments, so here's part deux.

To the right is a sanitized example of a hierarchical federated EA model*. At the top level of EA Framework reside the Reference Models. These models are quite flexible and can accommodate multitude of notations and purposes - some examples would be SOA Reference Model (from OASIS, for instance) or PMI Reference Model better known as PMBOK. In short, these are the "meta" portions of what we do and how we do it. They provide the vocabulary and rules of engagement. Whether they are acknowledged formally - or not, as the case may be - these models are in use in every single for-profit and non-profit entity.

Within these reference models reside Reference Architectures. So why are Reference Architectures valuable? The real value is the glue that they provide between conceptual realm of Reference Models and the two Brick and Pattern layers below. The Reference Models have a level of complexity that is difficult to translate into working process and technology. The value of Reference Architecture is in complexity reduction that is suited for implementation. For example, a Security Reference Architecture would contain Architecture Patterns (logical solutions for technical security capabilities like Authentication, Authorization, Access Control, et al) and Physical Patterns (here's how our organization implements role-based access control in J2EE-based application layer or here's how our organization implements authorization for .NET-based application layer, etc.)

ROI of any such Reference Architectures to an organization can then be tracked through the adoption of these patterns in both pre-project and project activities. While concrete value is through implementation, to quote Deming: "In God we trust; all others must bring data." If these patterns are implemented, but nobody collects metrics to validate and update ROI for Reference Architectures, it never happened. Also, collecting useful metrics on value through adoption must start when a project is in planning phases. Comparisons between Ref-Arch based solutions sets and point solution sets should be a part of decision-making process (that may sound like heresy coming from a former Chief Architect, but point solutions do have their place in our tool belt.) True costs and value of these decisions need to be documented and presented to the stakeholders who own the P&L that is impacted both before, during and after projects. I've never heard of a stakeholder frown during "here's how much money we saved you this quarter" portion of a regular update - as long as those numbers were backed up by agreed to and solid metrics.

That brings me to the "gray" row in the Reference Architecture Hierarchy. The color choice is apt because there is a tremendous amount of ambiguity involved in connecting Reference Architecture artifacts with Projects. Successful linkage depends on many "soft" things like organizational culture(s), human resource strategies, and stakeholder alignment - just to name a few. Without implementation of methods and processes in the "gray" row, however, there is little chance that those who promote, and sometimes evangelize, the concept of Reference Architecture will be able to demonstrate value on a sustainable basis.

AAB

* Domain Architecture Frameworks are not necessarily the same as the Enterprise Framework for some Business Operating Models. For Business Operating Models that do not require federation across business units, this may not be applicable so EA and DA levels can be combined.

IT Finance: Why Capabilities?

2009-11-10T20:54:00.001-06:00

Why is Technology Investment Management Method (TIMM) focused on Capabilities?

If we look at the IT finance arena, from which viewpoint we would like to valuate an IT investment, the investment should look like something multiple stakeholders can easily comprehend in the same or similar way. Such an investment must have boundaries that are semantically clear. And clear means clear to the customer who would attribute value to the investment.

Traditionally IT systems, and all types of staff have been targets for valuation. Departments, divisions, products, customer acquisition systems and backend processing systems, infrastructure all fall into the current valuation perspective. But if that mix feels a bit disjointed then it could be a problem. Departments, divisions, etc. are all things in the generic sense but they’re not peers. Some of them depend on others. Also they don’t always resemble each other enough for a fair comparison much less a comparative valuation. There are too many details to manage in an annual planning effort.

So what to do?

By talking to your IT consumers and using the capabilities they want to qualify their goals you will move away from telling them about your services to a dialog about how you can satisfy them. The capability approach uses a consumer perspective to define consumer investment and it is based on their language and knowledge.

From Marketing Myopia, Harvard Business Review, Jul 01, 2004 by Theodore Levitt, “It is constant watchfulness for opportunities to apply their technical know-how to the creation of customer-satisfying uses that accounts for their prodigious output of successful new products.” Mr. Levitt was writing about Dupont and Corning but the same holds true for IT Finance and how IT Finance can serve their customers, consumers of IT services.

Organizations have many consumers, business, technical, risk, and human resources at a minimum. Each of these groups look at their organization in a different way. Each requires its own view. But the views sometimes overlap slightly and they clearly interconnect in support of each other.

So TIMM uses the detail of all these systems, technology infrastructure pieces, departments to validate what we call Capabilities. These capabilities are lightweight, logical, abstract, conceptually meaningful to stakeholders from one area to another in the consumer pantheon listed above.

Using capabilities with which to plan gives all stakeholders a handle on a range of topics that they can easily identify and comprehend in the same way across consumer disciplines (the pantheon again). And because they can easily understand what they are, the valuation task becomes much simpler and direct.

That is an important breakthrough and a big deal.

Poll Results

2009-11-05T09:38:00.003-06:00

For the month of October, we asked our readers which Sample Capability Map would be of most value to them. Of the possible answers (Enterprise Architecture, Office of the CIO, Technology Finance, Governance Risk and Compliance, and Portfolio Management) it wound up being a tie between Office of the CIO and GRC. So look for these two sample capability maps to make an appearance in the next two months!

Thank you for your participation,

Aleks

Chatting Up the Relationship between Capabilities & Projects

2009-11-02T08:00:00.005-06:00

The posts on this blog have mentioned capabilities quite often. I thought we'd dive into the relationship between capabilities and projects for a moment. Here we go...

Can a project embody a single capability at a time? Yes. Can a project deliver multiple capabilities at the same time? Yes. Can multiple projects deliver a single capability? Yes.
Is there a preferred relationship of projects to capabilities? Yes, there probably is -- and the relationship most relevant to your corporate planning culture is likely different than the relationship most relevant to anyone else’s corporate planning culture. We are at the beginning of our understanding of business capability-based project planning. There are no ‘best practices’ as of this writing.

But still, why are there so many possible project-to-capability combinations? The reason is that different layers of capabilities represent different layers of granularity. The closer you move toward the technology layers, the more granular the layer becomes. As the granularity
approaches the typical project granularity in your organization the more comfortable you will be in seeing the capability as a project candidate.
A sample process that determines project-to-capability relationships should work something like this: First perform the capability identification and analysis; that is, identify the high level capabilities and then perform the decomposition. After you have two or three levels of capabilities and their dependencies see if you understand their value to the business. Value as well as dependencies determines build order. After that, see if the capability granularity makes sense to turn the capabilities into projects. Here is a quick view of the same:

Figure 1 – Quick Path Capability Identification Process

Some people will have trouble separating the abstraction for capabilities useful in planning from the exercise of identifying capabilities for projects. But good governance practices such as separation of duties can help. Separate the analysis from the project identification phases and let different roles address those steps.

If you’re having difficulty breaking capabilities into projects, the capabilities you’ve identified are either too broad or too granular for your corporate planning culture. Try rolling them up or decomposing them further for better results. Organizations that employ capability-based project planning will find that they develop new terminology around projects. Communicating the value of your projects will become easier. Capability-based projects will be in the language of your domain because capabilities are already in your domain’s language.

For more information download the white paper: Will the Capability Revolution Cause Project Evolution? (July 2009).

Update: $6.2T Mistake Revisited

2009-10-22T20:44:00.009-05:00

A spirited conversation on Twitter with @PeterKretzman and Roger Sessions (@RSessions) led to a couple of updates:

Factor = 5.4 * .24 * .0275 = .03564

Total Yearly Loss: .03564 * $69.8T = $2.487T (round up $2.5T)

Editorial Comment: While $6.2T seemed too high , and $414B seemed a bit low, could this be the real number? Details below:

1. Updates to my math:

Roger's definition of indirect costs adds expended cost of failed project to both tangible and intangible benefits. So, to use my example of 50% ROI, 60% of benefits are intangible example, the multiplier would be 100% + 150% = 250% or 2.5.

That thought experiment assumes a very strong business case. Available research further confirms that experience: "Nucleus case studies reveal that, on average, indirect benefits account for half of technology ROI. " (Nucleus Research, 2004). In my experience, most organizations have hurdle rates around 20%, not 50%, so very few approved projects will have benefit case with 50% ROI. So, let's take 20% as our floor (2.2 multiplier). Example cited in Roger's white paper seems highly unusual, but it does provide a ceiling (9.6 multiplier). A question without a good answer is what is the distribution of project spend between 2.2 and 9.6 - my hunch is that even if it is a bell curve (normal distribution), it's far more weighted toward the floor in terms of number of projects, while far more weighted toward the ceiling in terms of spend. If we assume those two cancel each other out, the average multiplier becomes 5.4. I'd be interested if anyone has done a study to support/update this number, rather than using an assumption.

2. Updates to Roger's math:

I still find it curious that Roger and I are using the exact same research note from Standish Group to get the ratio of failed projects - but using different metrics from that note. I take the definitions from Standish more literally - it's hard for me to argue that their definition of "failed" is not sufficient, especially since they clearly delineate between "failed" and "challenged". So I'll stick with 24% failed metric from 2009 report. Whether there are some incurred indirect costs of "challenged" projects is an open question - it makes sense that there would be, but I'd love to see a study rather than make that assumption.

3. Open questions

First, it would be nice to have a metric supported by research on what the multiplier should be. That is the biggest weight in the equation, and it needs to be more than assumptions on all sides.

Second, there are obviously indirect costs to challenged projects. I'd be interested to see whether anyone (ahem, PMI?) has done a study that documents the costs of missing deadlines. That will also have an impact on the final answer, though probably not as much.

Why Reference Architecture(s)? (Part 1)

2009-10-12T09:18:00.010-05:00

A few weeks back, I posted a sample EA Capability Map. It generated a lot of discussion here, on Twitter and LinkedIn groups. Within these discussions, one of the insights from the map - Reference Architectures, specifically Business and Technology, are the business of Enterprise Architecture - was routinely challenged. These challenges came from many perspectives - the uber-pragmatist EA movement objected to investing into shelf-ware, the semantic pedants wondered what my definition of Reference Architecture was, the decision makers have never seen this expenditure justified by ROI, and so on. This was contentious enough to warrant a detailed treatment.

As I got into writing about the "why", I found a strange thing - the semantic pedants were more accurate than I gave them credit at the time - there is little to no agreement as to "what" a reference architecture is. While there are many perspectives on what a Reference Architecture provides, there is no "one" definition. So I'm scoping this post to just the "what", and leaving the "why" to Part 2. The intent is to get enough reactions and opinions to crowd-source a definition of Reference Architecture that can replace what is currently in Wikipedia (see below).

1. What is Reference Architecture

There are many definitions, which is part of the problem. The other part is that few actually define Reference Architecture. Here's a representative definition from Wikipedia:

A reference architecture provides a proven template solution for an architecture for a particular domain. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.
A reference architecture often consists of a list of functions and some indication of their interfaces (or APIs) and interactions with each other and with functions located outside of the scope of the reference architecture.
Reference architectures can be defined at different levels of abstraction. A highly abstract one might show different pieces of equipment on a communications network, each providing different functions. A lower level one might demonstrate the interactions of procedures (or methods) within a computer program defined to perform a very specific task.
A reference architecture provides a template, based on the generalization of a set of successful solutions. These solutions have been generalized and structured for the depiction of both a logical and physical architecture based on the harvesting of a set of patterns that describe observations in a number of successful implements. Further it shows how to compose these parts together into a solution. Reference Architectures will be instantiated for a particular domain or for specific projects

Note, nowhere does the definition say what Reference Architecture is! There is plenty on what it provides, what are its building blocks, etc. No wonder Enterprise Architects can't agree on whether it is even needed.

So here is my definition:

A Reference Architecture is a set of predefined problem solutions for a given perspective.

To me, the implication is that while there may be Business Reference Architecture, a Technology Reference Architecture, a Risk Reference Architecture, an Organizational Reference Architecture, an ... Reference Architecture. But there isn't "one" Reference Architecture.

Your contributions are encouraged and welcomed!

Aleks

The Holy Grail of Enterprise Architecture?

2009-10-07T09:58:00.002-05:00

There's been several conversations in LinkedIn groups on existence of a list of Enterprise Architecture Guidelines. These questions have been asked from a Governance point of view (how does my organization assure that projects comply?), from a theoretical point of view (is it possible?), and even from a sharing the pain point of view (why is there such a resistance to following our guidelines?!) Of course, if such a list exists, it could be tremendously useful to quickly creating Enterprise Architecture programs. So it's an intriguing thought, but is it just that - an interesting thought exercise?

Theory first. My apologies in advance for mathematical hue of the response, but this question can best addressed by a branch of mathematics known as set theory.

Let's say such a list exists, then what are the attributes of these guidelines?

They would need to be almost infinitely customizable to account for every possible combination of organizational growth by every organization.

They would have to address all business/public verticals, multiple business operating models, all business outcomes (good, bad, and ugly)

They would have to somehow tie all organizational processes and services to the business outcomes - arguable one of the more important roles of EA.

And that's just a start.

I did, however, say 'almost infinite' - which is by definition, discrete. While each organization is unique, there is a discrete number of organizations. Their growth patterns and responses to challenges are even more standardized thanks to normalization. So mathematically, a set of guidelines that accounts for all these variations must be discrete.

That's the theory, now reality: while discrete in nature, a list of possible guidelines would still have large enough cardinality to be unusable. And that's before we start considering unique organizational circumstances. Anyone can quote from the gospel of best practices on how to build pure software. Unfortunately, purity is not equivalent to good business - "perfection is the enemy of good" goes the quote. Yes, it can be easy to slip down the slippery slope of "good enough" to bad outcomes, but managing that risk is the job of any oversight organization such as Enterprise Architecture. Here are a couple of practical examples of where best intentions can lead:

Reduce the number of non-core business processes that perform the same or similar functionality as a method for reducing cost.

Hard to argue with this as a guideline, especially in current economic times, right? However, process optimization has been a fertile field for both tremendous success and catastrophic failure. If the organization is comfortable with the price point of existing operations, why would it want to disturb what already works when it has 31% chance of success? I understand that these operations may be messy. They may not be elegant at all. They might even involve Excel spreadsheets and Access databases and email-based workflow. They do have a tremendous advantage over any project proposal: they work today.

Reduce the number of unique data structures passed between systems

Believe it or not, sometimes this is not desired. Anyone who's been in Data Management space for any period of time knows that it's nice if everyone needed the same data all the time. Trouble is, it never happens. Different perspectives require different information at different times. There is nothing neat and predictable about how business uses data. Hardly anyone is willing to wait an additional week for their information to be presented in standardized format when decisions are needed right now.

Loose coupling of systems and process

This is one of the pillars of Service Oriented Approach. But much to the dismay of the adherents of SOA Grand Unified Theory, value of SOA and even its applicability are heavily dependent on business operating models. So the real question is: how much loose coupling is enough? Are there, in fact organizations where loose coupling is a bad idea from a business perspective? There are plenty of examples where this guideline could introduce too much organizational complexity, or too much risk against the asset portfolio.

I'm not just trying to be a contrarian here. What these examples should highlight, however, is that Enterprise Architecture Guidelines are entirely beholden to many things - business goals, business models, business operational models, stakeholder perspectives, among others. Trying to assemble a list of such guidelines is difficult at best because a lot of them will be contradictory. What it resembles most is a decision tree with each organization's 'as is' and 'to be' states as inputs. Without that, at worst, this exercise can become a hunt for "Holy Grail" of Enterprise Architecture. So rather than concentrating on compilation of such a list, I would advise focusing more on the process by which such a list could be compiled for a given organization. We often hear that right level of "granularity" is crucial when it comes to good systems design. Since an organization is just a system of systems, shouldn't that principle be applied in this case?

Aleks

A $6.2T Mistake

2009-10-01T16:30:00.004-05:00

Perhaps I have an overly developed sense of smell. Or maybe it's my background in statistics that makes me a skeptic. Or having to sit through hours of vendor presentations about what features will be released in the NEXT version of their product. But when I read Michael Krigman's latest post on Roger Sessions' calculations of how much IT failures cost on an annual basis, it tripped several "are you kidding me?" alarms. So after a brief exchange with Michael on Twitter (@mkrigsman), he suggested that I look at the calculations and see where I disagree with Roger's results.

Fair enough. I spent a few minutes analyzing Roger's argument with simple math and readily available research. Here's the treatment:

According to the World Technology and Services Alliance, countries spend, on average, 6.4% of the Gross Domestic Product (GDP) on Information Communications Technology, with 43% of this spent on hardware, software, and services. This means that, on average, 6.4 X .43 = 2.75 % of GDP is spent on hardware, software, and services. I will lump hardware, software, and services together under the banner of IT.

So far, so good.

According to the 2009 U.S. Budget, 66% of all Federal IT dollars are invested in projects that are “at risk”. I assume this number is representative of the rest of the world.

66% is a fair number. As I blogged earlier this year, project success rate has stagnated at 31% +/-3% over the past 8 years according to Standish Group. The assumption in the second sentence, however, starts leading Roger's analysis off the rails.

A large number of these will eventually fail. I assume the failure rate of an “at risk” project is between 50% and 80%. For this analysis, I’ll take the average: 65%.

That's an interesting assumption that leads to ~43% failure rate for all projects. That's questionable at best, since the actual failure rate of projects was 24% for 2008 (Standish, 2009), and has been fairly constant over the last decade (31% +/- 3% success, 45% +/- 3% challenged, 22% +/- 3% fail). That eliminates roughly 45% of the $6.2T figure, leaving us with $3.46T. However, now that Roger's analysis is fully off the rails, it goes off the beaten path as well:

Every project failure incurs both direct costs (the cost of the IT investment itself) and indirect costs (the lost “opportunity” costs). I assume that the ratio of indirect to direct costs is between 5:1 and 10:1. For this analysis, I’ll take the average: 7.5:1.

Not sure what this assumption is based on. Most organizations will gladly take 30% ROI when embarking on a project. In all of the CBAs that I've had the opportunity to be a part of, intangible benefits were quantified from 30-60% of the overall benefits. So let's take a generous outlier: 60% intangible benefits, 50% ROI. That still works out to... 9:10 opportunity cost to program cost (invest $100, get $150 back, 60% of $150 = $90). To get to 7.5:1, both the ROI and intangible benefit numbers have to be of magnitude rarely seen in business (working backwards: for every $100 spent, get $750 in intangible benefits plus some tangible benefits - where do I sign up?!)

Based on the sober analysis above, the expected cost of IT failures is:

.9 * .24 * .0275 = .00594

of an "average" country's GDP.

So even ignoring the fact that not all countries can be treated the same for purposes of normalization (that would tremendously impact what "average" and "mean" numbers really are) the total cost of IT failures comes out to $414.6B per year (if we use the numbers for GDP in Roger's analysis). That may sound low in comparison to $6.2T, but I would be happy to solve even 24% of that number. What it underscores is that IT project failures are a serious problem that deserves serious treatment.

Aleks

edit: based on @PeterKretzman suggestion, added links to Standish Group's 2009 Chaos Report

Avoiding the BOMM (Business Operating Model Mismatch)

2009-09-25T12:26:00.013-05:00

Thanks again to OMG and Brenda Michelson and Karen Larkowski at SOA-Consortium and BPM-Consortium for putting me on the schedule for the special meeting last week in San Antonio. When I was asked to participate, the guidance on topic selection could have been perceived as daunting - rather than look into internals of how to construct #SOA or #BPM, I was asked to broaden the horizon and consider opportunities opened by leveraging these approaches in the real world. My initial response was - "so, you want me to go from "Whoa, #SOA!" to "What could I do with this given an opportunity?" posture? No problem!"

I had a lot of interesting interviews and research in creating this presentation. Most people only see the results of M&A gone wrong on the front pages of newspapers, news, or talking heads shows. As I continued to dig into the space, I realized that one of my favorite soap boxes applied here just as well as it applies in Project Management world. Success (or more likely) failure, depends far less on easily quantifiable benefits like cash on hand and real estate owned than is given attention to during most integration strategy and planning meetings. It depends far more on intangible organizational assets - culture and people. As the Hewitt and Associates study shows, 90% of integration planning is spent on accounting, financials, and operations. Yet 80% of what goes wrong is attributed organizational culture and departure of key resources. The easily quantifiable "stuff" has dependencies on these "squishy" topics, and it's clear that a lot of merging and acquiring organizations find the successful outcomes elusive because these dependencies are not properly documented and addressed.

As part of illustrating what could go wrong, I created this handy TSA-Style Threat Level Chart based on the "Enterprise Architecture as Strategy" book by Jeanne Ross et al from MIT Sloan School of Business. The insight of "Know Thyself" applies doubly here - to both organizations. And while the colors are only warnings and not deterministic indicators of outcome, the amount of attention given to non-easily quantifiable areas of integration planning should vary based on where your organizations fall on this chart. Another insight is that Integration Capability Portfolio can be used for internal integrations. As most large organizations are aggregates of smaller business units, optimizing positive outcomes of reorganization is an ongoing concern. The Capability-Based Approach planning techniques described in the presentation can be easily applied to the reorganization or internal consolidation scenarios.

Here is the link to download the full presentation. SOA-Consortium recorded the session, and I will post the link to the podcast once it becomes available.

Chris Curran asks: Can a CIO be Successful Without IT Experience?

2009-09-23T00:51:00.006-05:00

Chris Curran (@cbcurran) posted an interesting take on whether a CIO can be truly successful without IT domain experience. One of the more enlightening parts of the post is the diagram that captures 5 "functions" from Business Experience Only and With IT Experience. I can see a very natural transition of this table into our model with "functions" as "capabilities" and experience labels as two of our four minimum perspectives (Business and Technology). In fact, that is how one might start building the Office of the CIO with a Capability-Based Approach.

Back to my reply: it's an interesting premise, and one that is repeated many times in most environments I see. Larger companies tend to move 'high-potential' executive candidates to a less technical and more management "science" tracks. While I agree with Chris's premise that the optimal CIO should have both IT and relevant business experience, I have seen CIOs without IT experience succeed as well. One of the best was a CISO I worked for who actually studied, took, and passed a CISSP exam along with her technical resources - after working her way up through the general management track.

I found the example of the recreationally whining CIO quite instructive. The underlying issue wasn't lack of IT expertise - it was lack of trust in her "new people". Effective leadership is not about leading - it's about getting others to follow you, and that generally involves bidirectional understanding, if not trust. There are plenty of successful leadership patterns documented - even going as far back as Sun Tsu's Art of War. I'm not aware of any successful leadership patterns that involve calling one's team "them". Did the CISO in my example need to take the CISSP exam? Of course not, but it did gain her credibility with her new department despite lack of any security-related work in her experience.

As IT becomes increasingly complex at all levels of infrastructure and application development, CIO's ability to be successful will probably become more dependent on whether they can rely on people they lead for decision-grade information. It doesn't have to be direct reports - but there better be trusted advisers they can rely on. Without that in place, any organization that appoints a non-technically savvy CIO is in severe danger of mismanaging their technology investments.

New Blog Layout

2009-09-21T13:10:00.002-05:00

We've held back a few posts due to new blog layout debuting today. Expect a flurry of activity in the next couple of weeks!

- Integration Capability Portfolio reprise
- SOA/BPM reprise
- Thoughts on Talent Architecture
- Business Operating Models

Applying Appropriate Use to Enterprise Architecture

2009-09-12T08:27:00.007-05:00

There's been a lot of interesting banter - some expected, some not so much - around the Sample EA Capability Map that we posted last week. One of the more interesting insights centers around the appropriate use of Enterprise Architecture. Here's an interesting exchange between me and @JohnPolgreen on Twitter:

JohnPolgreen

RT @chrisdpotts Just reading phrase "business-driven EA" and its apparent tautology. Any "not-business-driven EA" (in a business) not EA.

JohnPolgreen

RT @RealLouwWe have to solve the problem of confusion Enterprise IT Architecture with EA bit.ly»

aleksb6

Re: @JohnPolgreen ... is that really a problem?

JohnPolgreen

Re: @aleksb6 There is a place for IT Arch, but, IMHO it must be predicated on knowledge of BA, and usually in direct response to bus imperative.

JohnPolgreen

Re: @aleksb6 ...example - large scale server consolidation - seems an IT arch exclusive problem. Needs at bare min anal of impact on bus

JohnPolgreen

Re: @aleksb6 ...EA PROJECTS may often go light on BA, the EA PRACTICE must focus on business value.

aleksb6

Re: @JohnPolgreen ... there is such a thing as business of IT. If predicated=aligned, I agree w you. If predicated=dependent, not so much

aleksb6

Re: @JohnPolgreen re: business value - agreed... convincing #CIO #COO #CEO of this is quite difficult

aleksb6

Re: @JohnPolgreen ... however, #EA is constrained by Biz Operating and Tech Operating models; in some cases only ETA is most appropriate

JohnPolgreen

Re: @aleksb6 but you agree that the overall practice should be EA, therefore bus focused, even if an ETA approach is used for specific projects?

JohnPolgreen

Re: @aleksb6 difficulty convincing Cxx of value of #EA is one reason #TOGAF recs going after low hanging fruit to gain trust - use ETA for this

aleksb6

Re: @JohnPolgreen ... my point is that in some operating models, only ETA is appropriate, not full #EA - it must be a conscious decision by biz

aleksb6

Re: @JohnPolgreen ... just as w other tools/investments, there is such a thing as appropriate use with #EA, whether #TOGAF gets that or not

aleksb6

Re: @JohnPolgreen re: #TOGAF recommendation: doesn't that approach further ossify #EA as #ETA in minds of biz stakeholders?

JohnPolgreen

Re: @aleksb6 ...but build up your #BA knowledge as you do the #ETA projects - "#EA by stealth". In the lng run ul hv EA & show its value to Cxx

aleksb6

Re: @JohnPolgreen ... malheuresement, in that long of a horizon, #EA is usually susceptible to Shutdown/Restart #eapitfall

About half-way through the exchange, I realized that there is nothing in #TOGAF or #Zachman (or other frameworks) around the concept of appropriate use for EA itself. They throw the entire classification framework and in TOGAF's case ADM as the way to do Enterprise Architecture ("Framework is THE answer #eapitfall"). Hence, it becomes fodder for practitioners to argue about what "real" EA is, relegating perfectly legitimate subset approaches to pariah status.

In response, following our standard SenseAgility Bulls-Eye model, Enterprise Architecture as a function (or as Capability Portfolio in our view) is constrained by the Goals, and further b y Operating Models of each perspective. So if a subset of EA is appropriate for a particular Operating Model, then there is nothing wrong with only doing that part of EA! For instance, if an organization is based on Diversified Business Operating Model, the only impetus for EA to offer Business Architecture-based services as part of Business Reference Architecture Capability is if that organization wants to change it's Business Operating Model. If not, that information is not consummable by anyone outside of EA, so why would you invest into that capability?

In summary, EA is like quicksilver running where the lowest common denominator allows it to run. It will look different for every business and even within each business as it matures. This is where frameworks can lead practitioners astray. They have an end-state that is uncooperative with the demand.

Enterprise Architecture Capability Map

2009-09-03T10:18:00.012-05:00

In response to tremendous volume of requests from analysts big and small, we've spent a few days 'cleansing' a mature EA Capability Map and cross-referencing it with the EA Services posts that Todd Biske (@toddbiske) has been collecting on his blog (posts here, here, and here) from various thought leaders in this space. We also considered Mike Kavis' (@madgreek65) thoughts on whether Enterprise Architecture is a good idea for smaller companies.

Before diving into insights learned (and shared with Forrester's Jeff Scott (@logicalleap)), a few notes about the diagram.

We use the standard SenseAgility Bullseye that includes four perspectives:

Business - defined as the business of the department in question, not the organization as a whole (upper left);
Organization - who is required to operate all perspectives (upper right);
Technology - what tools are used to operate all perspectives (lower left);
Risk - what controls are in place to mitigate threats to all perspectives (lower right)

The dependency lines are omitted on this Capability Map. There are other, more appropriate diagrams that capture these relationships.
For illustration purposes, we used one of the capabilities to show how services aggregate into capabilities. EA Education Capability (Org Perspective) breaks down into 5 services, with further dependencies to EA Tools Capability (Tech Perspective) and its two services.

So a first batch of insights:

As with any complex animal, it is the dependencies that drive the value of any EA organization. Inter-dependencies between EA Capabilities, Services, Processes, and external dependencies based on stakeholder alignment are the key to capturing, monitoring, and reporting on the value of EA.
Any Enterprise Architecture functions performs all of these capabilities - whether formally or informally. And formality is not really determined by organization size. The real dependency on organization size is the extent to which these capabilities are executed. Formal education program and engagement management functions, for example, would not be necessary in a small company like Mike's. They would be critical in a Fortune 50 company.
The Capability Map is an operating model for EA. It is not a roadmap on how to build or source capabilities. Since each set of stakeholders is a set of unique individuals, each organization is unique. Hence, healthy skepticism is warranted when someone presents a one size fits all EA roadmap.
Enterprise Architecture has very little to do with Technology perspective. Only 1/14 capabilities in our vanilla model deals with technology. By contrast, fully half (7/14) are organizational capabilities. This result should not be surprising - while a strong foundation in technology is a necessary skill set for any Enterprise Architect, business acumen, organizational awareness, and risk management are even more important.

More thoughts to come, especially with everyone's participation!

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

2009-08-25T10:29:00.008-05:00

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

2009-08-16T20:09:00.005-05:00

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?

2009-08-15T19:53:00.002-05:00

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

2009-08-13T12:36:00.002-05:00

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?

2009-08-10T12:55:00.001-05:00

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

2009-08-10T10:42:00.000-05:00

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?

2009-08-09T09:52:00.003-05:00

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:
Creating the appropriate translations to allow potential consumers to find what they are looking for in their language
Creating the appropriate translations so potential consumers can properly leverage service assets
Creating the appropriate incentives to spur adoption of service assets
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

2009-08-05T21:32:00.004-05:00

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

CIO Magazine: Forrester's Take on Project Management Metrics - Cont'd

2009-07-31T11:48:00.007-05:00

As one would expect, there was a lot of angst from the PM community on this article. Here is my response to the tunnel vision that seems to plague majority of those posts:

"I find myself in the minority of agreeing with a lot of what Meridith wrote. Perhaps the article took for granted a point those of us in IT Management are painfully aware of, leading to most of the conversation so far to focus on the weeds.

According to Standish Group's CHAOS Report, 71% (+/-3%) of all IT projects are considered failed or challenged - and that metric has been stable for the past 8 years. Yet, stuff gets done. Things go into production, imperfect as they may be, and business moves right along. So there is a huge disconnect between project success metrics and reality. And that disconnect is likely caused by perception created by insufficient project success metrics.

For all the folks that keep harping on the "cop out" point, perhaps you'd like to offer up a suggestion to deal with the ever-changing requirements problem that doesn't involve telling the business stakeholders exactly where to take their ever-changing requirements, a.k.a. "project change management" or "art of saying no". Regardless of how you communicate "no", it will still be received as "I care about your P&L less than I care about integrity of my process", even if your stakeholders agree with the logic of that "no". One of the more common complaints from the business side is that "IT always says no". Business is business - needs change due to market and regulatory pressures, so requirements have to adjust on the fly as well. If we are to believe that velocity of information is increasing, then the pace of change is not likely to slow down today or tomorrow. Politically and culturally, I think we should avoid a scenario where project managers have to say "no" more often than they do today.

Trouble is, current metrics derived from project definitions simply don't take that kind of disruptive change into account. That's likely because neither construction nor aerospace, where project management has been grown, had to deal with this challenge. Historically, if a project was challenged in those spaces, there was usually a set of tangible deliverables worked on by people with standard set of education using standard set of methods. Stopping/realigning/restarting a project could be successful. If an IT project is challenged, none of those are usually present - assessing code completion and/or correctness is always a challenge (if you can find it), getting the necessary resources is a common complaint even with skill sets that sound like commodity (like developer), and there are few professional certifications that accurately predict someone's real expertise. Add the ever-changing requirements challenge, and it is quite surprising that even 29% (+/-3%) of IT projects can be measured as successful. And the same set of issues are now plaguing the aerospace industry - whether it's the Presidential Helicopters or F-22 programs, just to name two that have been in the news.

So the question is not whether change is used as a "cop out" or "cover for incompetence", as suggested several times above. That kind of thinking taken too far leads to rigidity of thought that can not consistently succeed in a change-driven world. The real question should be, how should the "project" itself evolve to withstand the impact of real world, and what metrics are then relevant to measure success/failure once that evolution occurs."

CIO Magazine: Forrester's Take on Project Management Metrics

2009-07-31T09:20:00.003-05:00

One of the more controversial arguments from a prior post was that success metrics for a project used by a vast majority of organizations are incomplete to decide whether a project was successful. Well, apparently I'm not the lone voice in the wilderness on this! Great article on CIO.com by Meridith Levinson on the topic, citing Forrester research:

Common Project Management Metrics Doom IT Departments to Failure - CIO.com

I can see now why Forrester team, headed by Jeff Scott, took a very strong stance on capability-based approach to Business and IT Alignment a few weeks back:

"Business and IT alignment remains a top priority for CIOs and other business leaders. While many CIOs have made significant progress in gaining a seat at the strategy table, a gap remains in organizing and illuminating business executives' thinking in a way that drives consistent understanding throughout the organization. Business capability models provide a new approach to deepen the strategic dialogue between business and IT leaders and increase strategic coherence. These models can act as a "Rosetta Stone" that provides the translation between business concerns and IT concerns. Tying IT strategies, projects, and costs to business capabilities offers a view of IT that resonates with business executives. Enterprise architects should construct a capability map that CIOs can use to encourage a more meaningful dialogue with their business peers to guide IT investments."

It's great to see Capability Revolution gaining steam!

Who should you trust to make software investment decisions?

2009-07-28T11:29:00.004-05:00

I've been following a very interesting poll on LinkedIn over the past week. SAP asked, "Who do you trust to make software purchase decisions?"

Link to Polls on LinkedIn

Results speak for themselves. More on that later,

Aleks

How much should Your Organization Invest in PMO?

2009-07-20T20:11:00.017-05:00

Standish Group CHAOS report is one that I follow very closely. From 1994, when the first CHAOS Report came out, Standish has been following success/challenges of projects. Some of the numbers are very familiar to any of us in the software industry - 84% rate of failure/challenges, 45% of features delivered never utilized, and so on. Here's a link to a great interview InfoQ did with Jim Johnson of Standish Group in 2006 with numbers through 2004. Some of the graphs are quite interesting too - for those of you who see patterns everywhere, yes, they do follow the Gartner Hype Cycle curve too closely to be a coincidence. That is a discussion for another day.

So some history - the success rates have improved from 1994 to 2002. That coincided nicely with a tremendous amount of emphasis in project management in a modern enterprise. Improvement is nice, but bad is bad - at the best measurement point in 2002, only 34% of projects actually succeeded. And then, success metrics started dropping again. By CHAOS 2004, 71% were challenged or failed. By 2005, failure rates quoted by PMI were at 72%, and didn't account for projects that were not "too challenged" - close enough is apparently not just for horse shoes in project management. The last two measurements from Standish confirmed that even if the trend wasn't reversed, success metrics have settled near 31% (+/- 3% depending on year). In 2009, it was 32%. So what gives?

I would argue that there are two separate challenges at work here: that IT has been focusing on solving the wrong problem and that measures of success as defined by PMI are insufficient.

First, as an industry, we've invested a lot of money into project and portfolio management. Organizations have spent on methodology development and rollouts, project managers, on project management software, on portfolio management software, on expense management software, on vendor/procurement management, on... well, if it was in the PMBOK, it was justified. And if there is anything to be gleaned from the CHAOS Report numbers, is that all this spending was actually solving the 20% problem, and maybe not even 20%. For all the investment, the project success rates improved from 16% to 31% over the first 8 years. And they've been there for the last 8 years. It seems project management has reached the plateau of productivity, to use the Hype Cycle metaphor, and further investment into the space is coming up against the law of diminishing returns. That is of little consolation to a CIO who goes into annual planning armed with knowledge that two out every three projects that will be approved will not deliver on their clients' expectations.

Second, there may be another explanation. Somehow, some way, modern enterprises keep on working. Sure, some of that is due to spiderwebs of manual processes created to pick up slack for failing projects and missed requirements. But things do work, if inelegantly so. Based on that, some have questioned Standish Group's method for classifying projects as successful, failing or challenged. What if the aim is off - perhaps the real issue is in the success criteria of the projects themselves? Consider these two points:

Research suggests that 84% of organizations either do not do business cases for IT projects or do them for a select few key projects. (Gartner) Of the 16% that are disciplined in their technology investment decision practices, very few have organizational mechanisms in place to measure and manage to the business case once approved.
As I look on the bleak landscape painted by the analysts, we have come across case studies where an initiative should be judged a failure or challenged by conventional project management metrics. Yet they deliver tangible value in areas that were not identified, or could not have been identified when the initiative was approved.

The first point highlights that very few organizations definitively know the actual disposition - be it success, failure, or something in between - of all their projects. The second point highlights that while the concept of "project" is fairly well-defined, the success criteria are not, and that a more appropriate way to judge whether a project succeeded is to look at the short, medium, and long-term impact it has on existing and new assets. Of course, since 89% of organizations have virtually no metrics in place to measure IT effectiveness except for finance’s account of expenses (Gartner), measuring that impact can be even more challenging than successfully delivering a project.

Aleks

Thoughts on CAEAP

2009-06-22T10:24:00.005-05:00

I was honored to be invited to attend the kickoff meeting for the Center for Advancement of Enterprise Architecture Profession (or CAEAP for short). A lot of good ideas were discussed on how to harmonize the body of knowledge and training required for good enterprise architects. The problem is real - Enterprise Architecture programs have been one of the most consistent casualties of the current downturn, mainly as they are viewed as overhead and generally lack a standard way of communicating their value to the organization.

And yet, a highly functioning Enterprise Architecture capability is requisite for leveraging business process and technology assets in innovative ways to respond to internal and external pressures. Make no mistake, decisions on how to best utilize business processes and technology assets are made every day in every company. Most organizations simply cannot afford to wait months to gather the information to make a perfect decision. Without a formal knowledge management process and platform that ties all of the assets together, that discovery of information will always depend on few guru-level resources - not a very scalable approach - or will be relegated to the "we can't afford to wait or invest capital into discovery" paradigm.

Without Enterprise Architecture capabilities, that formal knowledge management process and platform cannot be created or sustainably operationalized. Without an advocacy body to harmonize the disparate threads and frameworks into a cohesive body of knowledge (a la PMBOK in Project Management), the cacophony of voices on how to best implement Enterprise Architecture capabilities can only degrade the value of EA message. This is why I believe that CAEAP's mission is crucial to Enterprise Architecture growth as a profession, and why I look forward to partnering with them to help them achieve their mission!

Aleks

Topics we're thinking about

2009-06-17T08:07:00.006-05:00

It's been somewhat quiet here the last couple of weeks, and not for the lack of ideas! As our thoughts about these ideas are getting more refined, here are some of the topics of interest for June:

- The limits of Project/Portfolio based approach to planning, budgeting, and delivery
- Creating and sustaining an Integration Capability Portfolio as a means of competitive advantage
- Resolving the (mostly) made up conflict between SOA and BPM - among others

Each one of these topics will receive a fairly detailed treatment - which for those of you who know us means that no stone will be left unturned!

Aleks

So much confusion!

2009-06-05T14:39:00.002-05:00

Lately there have been a lot of skirmishes between the various IT Advocacy Tribes - EA's, SOA Zealots, BPM Adherents, Data Minions, and such. The trouble is that everyone seems to think that their approach to solving the problems of IT is the "one true way in a dark and misguided world". So we get posts opining that SOA is dead, or BPM is too much change to be effective, or EA is too cloud-centric - and not in a good way. There has to be a happy medium between the various disciplines - after all, Nash proved that coopetition is far more efficient than competition a long time ago now. Perhaps we can check the sensationalism at the door and recognize that there may be smart people on the other side whose solutions are more appropriate in some perspectives of the overall problem.

This really hit home as I've been reviewing TOGAF version 9. A lot of good thought has gone into this release, but I can't help but think that they forayed into spaces that already have good problem definitions and appropriate solutions available. If The Open Group could have just focused on the Architecture Framework in version 9 without spending a lot of cycles on solving the Business Model, but rather formalizing the interface of their framework to accept the various solutions already in that space. Would that be Service Oriented thinking? Of course, that would imply that The Open Group understands encapsulation as a concept to be applied outside of technology!

Why does it seem so hard to measure the value of EA?

2009-05-26T09:01:00.005-05:00

There's been a lot said and written about the elusive value of Enterprise Architecture (EA). It's actually not as hard as we all make it. The value of EA, both tangible and intangible, can be measured in hard currency (of your choice). However, as an enabling function, that value is directly related to what the stakeholders perceive it to be. As far as translating EA metrics into currency, that process is unique to each organization due to cultural evolution and corporate goals and objectives. After all, if they were all the same, where could one derive competitive advantage? The value of EA, imho, is in strengthening organization's competitive advantage position - whether by enabling business units in reducing cost, increasing productivity, avoiding future costs, or enabling top line growth.

It is that uniqueness that makes EA so challenging for people used to patterns translatable from one organization to another - that is by definition, good architects. Not that these patterns don't exist - they absolutely exist, which makes it so tempting for an architect to generalize. The application of these patterns, however, is completely dependent on recognition of organizational behavior impact on architecture. Judging from the various trade publications and analyst predictions, the EA group is not usually successful in that application, which is why there is so much grousing about value of having such highly compensated resources around.

MITSloan CIO Symposium - Networked Organization Panel

2009-05-20T12:48:00.002-05:00

Moderator: Dr. Irving Wladasky-Berger

Panelists

John Stone, CrossTech Partners
Lorie Buckingham, CIO Avaya
Simon Crosby, CTO, Virtualization Citrix
Bilal Husain, Director of eServices, Saudi Government

MITSloan Symposium CIO Keynote Panel

2009-05-20T10:17:00.003-05:00

Moderator - Prof. Brynjolfsson

Bob Greenberg - General Manager IT Optimization IBM
Steve Schuckenbrock - Dell, Large Business
RADM Elizabeth Hight - Rear Admiral, Vice Director, Defense Information Systems
Jo Hoppe - CIO, Parexel

MITSloan CIO Symposium Panel 2

2009-05-20T08:52:00.002-05:00

Academic Keynote - the Future of IT

Moderator: Mr Gary Beach, publisher emeritus of CIO Magazine

Dr. Jeanne Ross (EA as Strategy, new book on IT Savvy coming)
Dr. Thomas Malone (predicted e-Commerce and sourcing in 1987)
Professor Erik Brynjolfsson

Questions and answers in comments.

MITSloan CIO Symposium - Panel 1

2009-05-20T07:45:00.001-05:00

8:45 - CEO Keynote Panel

Moderator David Roush, Xconomy

Joe Alsop, former CEO and cofounder of Progress Software
Bob Brennan, CEO of Iron Mountain
Jim Champy, Chairman of Consulting for Perot Systems
Alan Treffler, CEO of Pegasystems

Live Blogging from MITSloan CIO Symposium

2009-05-20T07:33:00.011-05:00

8:40 - Dr. David Schmittlein

Interesting survey - most people here have been to MIT before - bubble paradigm in effect?

Live blogging from the 6th annual event. Over 700 attendees, interesting, but not surprising that their event is growing while others are shrinking.

Follow up on Metrics posts

2009-05-19T14:34:00.005-05:00

Shiver me timbers!

Meaningful metrics needed to prove value of SOA

Even Gartner is getting into the incomplete metrics discussion now. Somewhat late, considering my analysis was partially based on THEIR studies, but glad to see they listened during our conversations last December :)

Aleks

Agility is Sensible

2009-05-15T15:43:00.002-05:00

We're live, and we're nationwide!

Here are links to several articles that I've been interviewed for:

How BPM and SOA work together for business process improvement

http://searchcio.techtarget.com/news/article/0,289142,sid182_gci1354936,00.html

Successful SOA means a long process made of small projects

http://searchcio-midmarket.techtarget.com/tip/0,289483,sid183_gci1354532_mem1,00.html

Update on travel calendar -

5/18, speaking on a panel at ACORD/LOMA on SOA and the Insurance Industry
5/20, attending the MIT/CIO Summit in Boston
6/20, speaking at the CAEAP Summit in Dallas on the challenge of managing architects
9/16, speaking at the SOA-Consortium Meeting in San Antonio

More to come, will post when available!

Aleks

Emerging Discipline of Disruption Management

2009-04-16T12:52:00.004-05:00

Interesting line of thought from Clayton M. Christensen from MIT/Sloan. Not sure I agree with Clayton's specific take on Wagoner. Also not sure whether "disruption" as an attack vector described in this article is somehow related to "disruption" as an attack vector that has been observed thanks to the ever-shrinking slack in the business cycle. The Big 3 were certainly profitable while the SUV and light truck market was booming, but were not able to cope with the sudden (or disruptive) retreat of that market thanks to oil price spikes of 2008 and credit crunch that is still with us.

Another discussion topic I think would be worthwhile to get comments on is whether service orientation of business and technology capabilities can really help deflect a disruptive attack - after all, just about every deck selling SOA I've ever seen has identified this as an intangible benefit.

Why incomplete discovery?

2009-04-09T06:57:00.002-05:00

So why would I attribute the top ten list from yesterday to incomplete discovery?

Every program (or product, or service, for that matter) has three stages of life - discovery, implementation, and operation. In reality, most of what people focus on when it comes to program/project management is the implementation stage. Maybe a bit of operations focus tossed in at the end to mollify those who will be running the results of the implementations (at least those that are not completely canceled!) It's not a surprising reality - people will do what they are incented to do.

Discovery is the stage that is usually left incomplete - or completely left out - in the rush to get to the finish line. Very few people like creating documentation, and even less like reading it. Even fewer can correlate the various bits of incomplete data into a cohesive view of the environment. And time lines are generally not built with discovery issues in mind.

Which brings me full circle to the idea of understanding the environment. First rule of information management can be summarized as "garbage in, garbage out". Is it really a surprise that when efforts base their implementations on data that is incomplete or assumptions that are no longer relevant, they fail at a prodigious rate? Invisible requirements? Scope Creep? Budget and resource challenges? Unrealistic time lines? Of course those lead to compromises in quality and features - even as those features are delivered late. So the sponsors get sub-quality features that don't necessarily match up to the features they need to deliver on their business promises, and they don't get those features in a timely manner. No wonder sponsors disappear!

OK, enough of the soap box. There are methods to quickly digest all of the environmental variables and integrate them into a cohesive road map. If only people would use them :)

It looks like the issue of incomplete discovery is quite pernicious!

2009-04-08T20:19:00.003-05:00

Not sure if everyone can follow this link, so I'll paste the post contents from www.mutoperformancegroup.com. It seems to me that just about every item in the top 10 can be attributed to incomplete discovery - or lack of discovery work. What are your thoughts?

Reprinted from LinkedIn's Enterprise Architecture Network:

2009 Results of the Top 10 Obstacles to Project Success Survey

Here are the new rankings from the "Top 10 Obstacles to Project Success" survey. We received appreciation for our ongoing efforts, and confirmation from participants that our list captured the essence of the obstacles to project success faced by Project Managers, Team Leaders, Program Managers, and Senior Management. Here are the results listed in order of frequency;

#1: SCOPE CREEP (Same as last year!)
#2: Challenging Schedule (up from #8 last year!)
#3: Resource Challenge
#4: Minimal or Non-Existent Testing
#5: Tardy Delivery of Project Tasks
#6: Delegated Responsibility Unrelated to Authority
#7: Finance Challenge
#8: Invisible Requirements (down from #2 last year!)
#9: A Skill Set Challenged Team
#10: The Disappearing Sponsor (down from #3 last year!)

We've had some interesting changes between the 2008 and 2009 surveys. Obstacles such as the Challenging Schedule, Invisible Requirements, and most notably, The Disappearing Sponsor have moved in their ranking.
What do you think causes these obstacles? What are some potential solutions?

Is "Enterprise Architecture" a misnomer?

2009-03-09T22:24:00.001-05:00

The role of an Enterprise Architect will continue to evolve as more and more technology and business leaders can buy into the value proposition of EA. As our duties evolve, their resemblance to architecture seems to erode - it's not about design as much as it is about design stewardship. It's not about technology as much as it is about people and financial management and strategic alignment.

While we can quibble over how many mature EA organizations really exist, the further we go on the evolutionary path of this discipline, the more it starts resembling a financial advisory model. Consider:

We diagnose organizational behavior;
We tailor our recommendations based on organizational risk tolerance;
We build our road maps based on gaps in business and technical capabilities
And we dutifully (if not in a fiduciary capacity) watch over the implementations, riding the emotional roller coaster with our organizations.

In short, the behavior of EA is most like a financial manager with a client that is investing substantial resources on an annual basis with a few well-defined exceptions: our basic indicators happen to follow Gartner Hype Cycle curve and the technical description of the assets and capabilities we manage cannot be described by tangible asset valuation alone. Of course, given what we've seen in the secondary mortgage market lately, neither could regular financial instruments.

So, a modest proposal - let's retire "Enterprise Architecture" and replace it with "Technology Investment Management"!

"Do not use a hatchet to remove a fly from a friend's face"

2009-02-19T19:07:00.003-06:00

For last week's post, I derived my inspiration from the Art of War. Channeling Sun Tsu was fun, but today, I am switching to something far more peaceful - Confucius. Call it Tao Te Value of IT? In any case, this is an old Chinese proverb found in Tao - "Do not use a hatchet to remove a fly from a friend's face." It surely predates Confucius, but he wrote it down. Sounds quite sensible, and yet the examples of non-sensible behavior persist when it comes to governance frameworks.

I type this after having the opportunity to review two governance frameworks - the shiny and highly anticipated TOGAF 9, and ValIT from COBIT. Doug Thiel also pointed me to Innovation Value Institute (http://www.ivi.ie), where yet another consortium is trying to create yet another unified value of IT framework. Forget frameworks - they should be classifying these as attempts at the Amalgamated Value of IT Theory (or AVOITT at all cost!). There is a reason I'm being rather punny about these frameworks - two reasons, actually.

First, each of these frameworks are written from a particular point of view. Technologists will be happy with TOGAF, Auditors with Val IT, and Operational folks with IVI. And yet, each of these frameworks seems to advocate being the "one right way in a dark and misguided world." Trouble is that while each of them is very thorough in covering their area of expertise, there are large gaps in other areas they purport to address. Yet another example of "man with the hammer" syndrome - or in for purposes of this post, "man with the hatchet" syndrome.

Second, just like the Theory of Everything being pursued by physicists, with superstrings and quarky dimensions, these frameworks leave no stone unturned. All the i's are dotted, and all the t's are crossed. Of course, one needs to kill a few trees to print each of these out. And for those executives who feel cold sweat when asked to sponsor a multi-year transformations in a big bang kind of way - well, the answer can be boiled down to "lead, follow, or get out of the way!" Trouble is, those executives are the ones who have to sign off on these transformations - in both budget and political capital. Given the kind of risk these approaches present to potential sponsors, why should anyone sign on? There are several large organizations that have looked at one or more of these and predictably recoiled. Especially in today's environment, the amount of risk is not something that can be ignored anymore. Perhaps each of these frameworks should come with a roadmap for implementation that allows potential sponsors to see progress (read: benefit realization) in shorter increments - say weeks rather than quarters/years.

Combining the two reasons above gets us to the quote of the day. Hence, the inspiration!

Peace,

Aleks

"Effort without planning is futile"

2009-02-10T07:57:00.003-06:00

In putting together the "Agility is Sensible" presentation for the IQPC Shared Services week, the project success rate stats really hit home -

In 2004, the Standish Group did a survey and found that 87% of integration initiatives do not deliver on their justification. 38% fail outright, and 49% underperformed;
In 2005, PMI study found that 72% of all projects underperformed in three critical categories: functionality, time, and budget. Of the 28% that weren't in that category, 62% are late, and 45% are over budget.
In 2006, KPMG study found that 65% of all mergers and acquisitions underperformed;

The key takeaway on my part here is not that projects fail. It's why they fail. In my mind, it comes down to the following four categories:

Doing the right thing
Doing the right thing in proper sequence
Doing the right thing with right resources
Doing the right thing the right way

In my experience, we focus almost all of our energies on the last bullet point. There are a bevy of methodologies out there. There are plenty of ardent supporters of each of them. But it is striking that with all the effort the industry has put forth to solving that bullet point, the first three remain more an art than a science.

Aleks

3 levels of integrated alignment - further thoughts

2009-01-08T07:33:00.005-06:00

In response to a question on LinkedIn, I also clarified some thinking around this topic. The reason why most of the tools we have to deal with any particular dimension of the problem space are wholly inadequate is because their focus is either too granular (think Six Sigma, LEAN, SOA, ISO 27k series) or too broad (Zachman, TOGAF, Goal-oriented analyses, COBIT). There's precious little that focuses on the middle that connects those levels of granularity. And that I think is where we get into real trouble - from one side, we can't see the forest for the trees, and from another too many things fall through the cracks of incomplete analysis. I'll post an attempt at a diagram later today.

Aleks

3 levels of integrated alignment?

2009-01-07T20:49:00.003-06:00

Earlier today I drew a picture of what a well-aligned enterprise would look like. That drew my attention to the fact that most of the tools we have in our alignment toolbox only focus on one aspect of one dimension. At the simplest, there are 3 aspects in 4 dimensions - is it any wonder, then, that every silver alphabet soup bullet to come out of the woodwork in the past 2 decades has not managed to live up to anything close to expectations?!

Aleks

Post-Holiday Tech Finance Thoughts

2008-12-26T10:53:00.003-06:00

I've been pondering this idea for a while, and would love some input -

Do accounting rules for IT need to changed completely or augmented somehow to deal with a process and service based world?

Aleks

Live Blogging from Gartner - Friday Thread

2008-12-12T10:44:00.002-06:00

Starting with a keynote about change. Some very interesting statistics and predictions from various studies about 2050, but a couple of things that don't make much sense.

First of all, given the political realities, I doubt that we can even inaccurately predict what the world will look like in 2050. Trying to predict what the world will look like in 2008 from 1968 would have been a fool's errand. Second, economic realities of the last 3 months suggest that the demise of United States as the world's lone superpower has been greatly exaggerated.

So here we have a preso that is still based on the 1st half of 2008. Good luck basing any predictions on that :)

Aleks

Live Blogging from Gartner - Thursday Thread

2008-12-11T10:57:00.003-06:00

Starting out with how to draw solutions on the back of a napkin. A very neat way to get people to try and visualize their problems with models. Should make a lot of sense to people in the room - Enterprise Architects. But outside of this bubble... Not sure how to crack the point that only 8-10% of the population is able to think in a model driven way.

Aleks

Live Blogging from Gartner - Wednesday Cont'd

2008-12-10T15:01:00.001-06:00

Start of EA sessions:

1st bombshell: Gartner predicts that up to 50% of EA programs will be suspended because of the economic crisis.

2nd point: Opportunity for EA has never been greater

Live Blogging from Gartner - Wednesday Thread

2008-12-10T10:38:00.002-06:00

Well, last day of the AADI (application architecture development and integration) conference and transition to the first day of the EA (enterprise architecture) conference. I'm taking a break from listening to analysts and going to listen to what National City has done. They had a representative on my panel, and it seems like they have their ducks in a row. However, as that rep quipped, you can have a wonderful technology strategy and execution, but when your business buys up MBS's and CDO's right before the financial meltdown, there's little IT can do.

Aleks