Enterprises were always important. A single person can only do so much, while people can achieve a lot more when they work together as a single integrated organizational body. The whole history of humankind could be understood as a natural selection of forms of enterprises that is heavily influenced by humanitarian and technological breakthroughs.
One such breakthrough — computers, and information technology in general — led to a form of enterprise that we now familiar with. Information technology is a new skeleton and information is a blood of any modern enterprise whether it is a commercial firm, or a governmental agency. The proliferation of IT lead to an emergence of a dedicated caste of engineers who are supposed to ‘set up’ a proper skeleton and a blood flow for enterprise be it a hardware, a software, a communication infrastructure, a particular way of doing things, or all of these at the same time. We know all of these deliverables as enterprise solutions, and the process of delivering them as enterprise solutions engineering.
It is not to be confused with Enterprise Architecture. If we push ‘bones and blood’ metaphor a bit more, EA helps to come up with an understanding of most important features of the skeleton, e.g. how many hands does enterprise need or what sort of metabolism keeps it alive. However EA doesn’t bother to give an answer on how to deliver the bloody stuff.
And there is a glitch. No one has a definitive answer on how to actually do enterprise solutions. This is something that keeps me awake at nights. No, there are engineers out there who deliver, but they are practitioners, not scholars. I’ve asked a lot of people I know for sure that there is a certain ‘methodological vacuum’ around this discipline. People use all sort of frameworks and processes to make an impression (mostly on themselves) that there’s ‘a proper way’, but what really is there is a lack of holistic approach to enterprise solutions delivery. And this fact has lots of implications. I won’t cite notorious reports about 75% of projects being failures, just remember if enterprises you work for deliver sensible IT solutions repeatedly and consistently.
Don’t get me wrong, there are a lot of various methodologies out there. During the ‘golden age’ of late 90-s and early 2000-s dozens of dozens of processes, methodologies and frameworks were invented, adopted, evolved and generally forgotten. Few survivors such as Rational Unified Process, a prominent magnum opus (and swan song) of Rational Software, are still in use. The problem is that most of such frameworks focus exclusively on the software development process, while the most challenging part lies somewhere else. It is the stakeholder engagement, needs analysis, defining systems’ boundaries, concept elaboration, candidate architecture selection, and making ‘buy’ vs. ‘build’ decisions that make it hard.
To be honest, software development methodologies acknowledge these needs, but usually fail to do so in a manner that is generic enough. Let’s take a need to weight ‘buy’ and ‘build’ as an example. A methodology may mention it and even provide some advice, but afterwards it normally proceed straight down the ‘build’ route, and you are left wondering if you should take it as a gentle hint that buying is for wimps. None actually provide any insight on how to ‘buy’ properly as if buying was an easy ride. And, of course, anyone who ever has built a solution on a foundation of the COTS product knows that it isn’t. For instance, in such a project you cannot normally do a top-down architecture as formal processes prescribe, nor can you let your architecture emerge as agile ones insist (in fact, they tend to acknowledge a need for top-down upfront thoughts as well, but it doesn’t help much). This is completely understandable by the way, as most authors are in fact software consultants, but, apparently, we should look somewhere else.
And there is something else. Half a century ago smart people in serious places like NASA Jet Propulsion Laboratory and US Department of Defence came to an understanding that they need ‘the process’ that will allow them to acquire new trinkets without ridiculous overruns in terms of time and money. What they came up with is now called Systems Engineering. It’s a set of practices, methods, and tools that prescribes how build anything complex in a predictable time and budget. There is a huge body of knowledge which could be used as a foundation to organize solutions engineering in any enterprise. Isn’t it what we are looking for?
However, the Systems Engineering body of knowledge is so vast, that a considerable amount of tailoring is required for each endeavour. Considerably higher than it is for RUP, for example. The tragedy is that the level of expertise necessary to approach the tailoring with any sensible likelihood of success is prohibitive for all but few enterprises.
Moreover, there’s another ‘flaw’ in Systems Engineering. Mainstream practice doesn’t usually deal with people’s side of things, assuming that human being is always outside of system boundaries. This doesn’t work for enterprise, as you almost always do something with people and business processes. Only recently an asknowledgement of this aspect started to get traction in a form of System-of-systems engineering (SoSE), but it is still a bleeding edge and there does not exist a single unified consensus for processes involved.
What is needed is a holistic approach to enterprise solutions engineering. One size doesn’t fit all so it cannot be a single overreaching process, but rather a discipline, or a framework used to construct and subsequently tailor a method appropriate to a specific solution and even to a specifict project phase. I’ve come up with a term Solutions Acquisition Framework (SAF) that serves as a place-holder for this highly desired discipline. Wouldn’t it be great if someone can produce one?