I’ve been reading a new 2011 edition of classic Systems Engineering textbook by Kossiakoff, et al., and it occurred to me that there is a significant difference between how enterprises normally acquire IT solutions and how Systems Engineering prescribes it to happen, which I haven’t previously paid attention to, and this is the source of many troubles.

The usual practice in enterprises is that IT projects start with an appreciation of a problem and an intention to uncover business requirements. The first project assignment involves an analyst and, potentially, an architect who are appointed to find out what are the problems of the business in a particular area and to put together a project brief. The latter is supposed to provide enough justification for an additional round of funding that would enable a certain activities to initiate the project, e.g. doing systems analysis, designing high-level architecture, putting together a business case — all your normal PRINCE2-mandated work items.

The principal consequence of this approach is that those initiatives become problem-driven. In itself it’s not a bad thing. Ultimately the value of IT is to support business operations and, obviously, if there is a problem in business operations that could be solved by IT a project will be commenced for sure. Of course, provided that there are budget and resources available. The bad thing is that the problem-driven stance of IT causes few adverse enterprise-wide effects .

First one is almost trivial. Since budgets and resources that the enterprise may spend on solving problems is limited, it is expected that problems would be fixed in a ‘future-proof’ fashion. If one got money to address an issue from the executive committee (or whatever governance body makes decisions on IT investments), then it is expected that the problem would disappear from the radar for a long time. Executives want problems to disappear, and they start asking questions if they don’t, so one has to have a very convincing story on ‘why do we need to solve that problem again?’ and ‘didn’t we already address the issue last year?’. Moreover, the more difficult is to get investment decision made in favour of a particular business function, the bigger the appetite for a ‘strategic’, once and for all solution. All of these means that most problem-driven solutions would be overkills, i.e. bigger and more complex than necessary.

Second effect is partially caused by the first. We all know that the business does evolve, and in most cases it is very difficult to predict how it would evolve exactly. And despite spending lost of money on highly flexible and, therefore, complex system, one may still end up with inability to accommodate new requirements easily. Given the fact that it is extremely difficult to justify additional investment on any such ‘minor’ occasion, a ‘tactical’ (quick and dirty) solution is often bolted on.

Finally, there is third effect which is the most dangerous, and it highlights the fundamental flaw of problem-driven solutions, which is the fact that it is based on an assumption that simply doesn’t hold.

The assumption is that there is a ‘norm’ out there which could be used to understand what to fix by comparing it with current situation. We’ve seen this approach in practice when we visit a doctor, who can easily tell whether one is sick or not by comparing his condition with a norm. Perhaps that’s why we got used to this kind of mindset.

Unfortunately, it doesn’t work for enterprises, as every enterprise is unique and, therefore, there’s no such thing as ‘normal enterprise’. In practice, instead of that, every decisionmaker has his or her own idea of what the normal enterprise has to be, and that idea is used to estimate the importance of a particular problem. Needless to say, the ‘idea’ is never documented, and, consequently, never stays the same.

Ultimately, such practice leads to proliferation of locally optimized pockets in the immediate vicinity of powerful and loud decisionmakers. This state of affairs might be working, but rarely anywhere near offering optimal support for long-term strategic objectives of the enterprise.

Considering all above, I’m strongly convinced that problem-driven solution acquisition is not optimal by for enterprises to evolve their business systems. Fortunately, systems engineering practitioners already know better way, which is widely used in industries such as defence and aerospace. It’s called capability engineering.

Capability is neither a system requirement, not a problem statement. Formally it’s defined as intentional or automatic ability of the system to assure specified course of action. In systems engineering we talking about capabilities of system-under-design as a way to get understanding of what the system is, i.e. the first step of system materialization.

Capabilities live in ideal to-be picture of the relevant part of the world. We just ‘fantasising’ about the final state where we’d like to arrive at some point, and we use the picture to understand what the system has to do for us to make it real. The whole business of capability engineering is about methodical invention, refinement and acquisition of the desired capabilities.

The idea could be easily illustrated by example from defence sector. A military doctrine of a country, ‘the constitution of warfare’, usually elaborates on the kinds of adversaries the country may need to engage (e.g. terrorists or insurgents), context of engagement (e.g. nearby countries or worldwide UN-mandate-driven-nose-peeking), and terms of engagement (e.g. low casualties). Then, the general staff performs ‘gap analysis’, i.e. considers whether the country has weapon systems and personnel to cope with every likely clash, and, if not, starts the acquisition process to obtain what’s missing. The acquisition process involves subcontractors who are given requirements in form ideal world scenarios, e.g. ‘detect and intercept an intercontinental ballistic rocket started from anywhere on the globe not later than in 5 minutes after the launch’ or ‘neutralize hostile forces in tundra-covered terrain’. Those scenarios or ‘wishes’ are examples for what is called a capability.

Enterprises usually don’t have doctrines, but they often do have stated missions and business strategies, which elaborate on what are its target markets, and what is the approach to being competitive. Alas, rarely a consideration is given to what capabilities are necessary to effectively support business strategy.

It would be fair to say that some modern enterprise architecture frameworks do acknowledge the need for ‘capability-based planning’ (e.g. TOGAF has a chapter on it). In theory it looks promising. However, in my rather limited experience I haven’t seen it done in practice yet, and quick poll among my peers indicates that it’s not only my impression.

I strongly believe that approaching enterprise solutions acquisition in a way driven by capabilities that are derived from the business strategy is the only way of overcoming identified deficiencies of problem-driven approach, i.e. overkills, lack of agility, and local optimisations.