Solutions requiring more than a single implementation technology could be tricky. An enterprise software project could easily include 4-5 technologies. You could easily have a team working on a Flex front-end, another team developing Java-based backend, an integration team armed with BPEL and numerous connectors to external systems, infrastructure folks who are supposed to come up with specifics of actual deployment, and a couple of contractors looking after legacy MUMPS application, services of which have to be exposed as part of the resulting solution. Throw in a COTS application that have to be adopted to cut development cost, and a mission-critical deadline set to 1st of January when a new revision of regulatory requirements come into play. Quite a challenging environment to work in.
Apparently, Systems Engineering discipline was facing the same challenge since its inception. Even a modest space mission requires coordination of efforts of engineers having together a dozen of specialities, e.g. jet propulsion, optics, telemetry, electrical engineering, ground support to name a few. All these people, albeit being smart, don’t really understand each other’s domains. There was a clear need for partitioning the whole mission scope into work items that could be given to a specialist team. And the result still was supposed to fly well. Sounds familiar?
The answer was a thing called design loop. Essentially it is interleaving of analysis and design activities in order to settle on a particular physical architecture. The prerequisite of the design loop is requirements analysis exercise which yields a set of functional and non-functional system requirements, a different story, but the design loop itself proceeds as follows.
First, the system of interest is partitioned into an arrangement of functional components. There are potentially infinite number of ways to partition the system, so natural boundaries of the solution domain are considered first, e.g. disciplines (mechanical vs. electrical), rate of change (chassis vs. equipment), mission stages (launch site vs. in-orbit) and so on. A candidate partitioning that looks most promising is selected.
Second, system requirements are allocated to functional components. There are two basic techniques to achieve this. Either a single component made responsible for a particular requirement. In this case system requirement becomes a component’s requirement. Alternatively, a decision is made on how several functional components would address the requirement by working together. In this case requirements for participating components are derived and captured. Ultimately, a set of interrelated requirements for functional components is constructed. This is what’s called a functional architecture.
The beauty of this approach is that allocation works for both functional and non-functional requirements. For example, if you need the satellite to weight less than 50 kg, then you need to assign a particular weight limit for each functional component so they add up to a smaller number. The same for performance characteristics, such as latency which requires that response times for all interacting components in sum are less than a particular system-wide threshold. Not surprisingly, it works equally well for cost, scheduling and risk constraints.
As a sidenote, I’d like to point out that SysML does a fantastic job of capturing non-functional quantitative requirements (e.g. performance) via its Parametric Diagrams. I’ve previously pointed out a good showcase on SysML that demonstrates exactly this. There are tools that could run consistency check on your allocations to see if you are running into contradictions such as negative mass or infinite speed.
Third, requirements for each functional component are considered and candidate physical implementations are designed. The goal is to satisfy all functional and non-functional requirements at the same time. The presence of cost, schedule and risk constraints ensures that resulting design passes sanity check. This stage is where specialist engineering comes into play. For example, only optical engineer can tell if it is possible to construct a set of lenses having required zoom factor within given space or mass constraints. Similarly only structural engineer can tell if a particular form could be made structurally sound in the presence of anticipated load. Sometimes it is uncovered that it is simply impossible to build a component up to requirements, in this case a candidate implementation with properties closest to required is proposed. Anyway, the result of this stage is a set of implementation proposals for all functional components. This is what’s called a physical architecture.
Not surprisingly, it is unlikely that physical architecture on the first iteration would be sound. Mutual exclusive and conflicting properties are quite normal as there are not a lot of common engineering sense available for greenfield developments. In this case an alternatives for both physical implementations and functional arrangements are considered, and various trade-off analyses are conducted. Process loops to any previous step with these alternatives. As final resort, when all alternatives were rejected, a system requirement that happens to be the most constraining one could be elevated. Since both component requirements and candidate implementations define characteristics within margins, the math required to balance the whole thing quickly gets complicated, so things such as constraint solvers may come handy.
The design loop continues until system requirements, functional and physical architecture settle down, i.e. there are no conflicts and all (possibly revised) functional requirements are covered. At this stage architectures are declared baseline, and the following stages (detailed engineering specifications, components implementation, assembly, verification, and validation) are executed according to the baseline. Of course, there still is a place for changing the baseline, given that a proper configuration management practice is in place.
Note, I deliberately provided examples outside of software engineering field. However, I’m strongly convinced that this process fits quite naturally for managing architectures of complex enterprise software endeavours, like the situation I’ve described in the first paragraph. In order to survive through that jungle you have to approach it in rigorous way. There’s no other way around, otherwise the progress would quickly halt because of endless rework and/or integration nightmare.
As a good Solutions Architect you will do something similar to the following. First, you come up with possible partitioning of effort, carefully considering functional components and possible team structures. You will think about Agile-ish cross-functional teams as opposed to traditional technology-focused teams. You will consider staged delivery to reduce risk and bringing in contractors to speed up the development. And definitely you are not doing in alone, as you need an input from resource managers, business sponsors, local neighbourhood IT governance bodies, and other important stakeholders.
Seeming difference from the classical SE in the fact that we are not dealing with a variety of engineering disciplines, but ‘just’ with several implementation technologies. However, it hardly changes anything. Even of you have a single technology, but multiple components to be developed by different teams, you still have to partition and allocate.
Second, you will allocate requirements to functional components and delineate interfaces. Traditionally, enterprise software has more emphasis on functional requirements rather than non-functional ones, as software exhibits quite a few physical properties to care about. On the other side, interfaces play much more important role, so you may find convenient to use interface management techniques such as N-Squared diagrams.
Third, you will work on candidate implementations with all prospective delivery teams. Normally paper-based exercises or prototypes are created at this stage, as it is imperative to make sure that it is actually possible to build things up to the functional architecture. You will have to collect estimates for all physical components as well to see if you fit into the bill and hard deadlines. Usually it doesn’t from the first attempt, so walking circles around developers and asking for re-estimation is something to expect. This is where real fun begins, because you have to balance a lot of forces and manage expectations of numerous stakeholders, so unless you’ve got a really good functional architecture that can answer questions, you’ve got a problem.
* * *
Why I’m looking into it? Because I’m trying to formulate a consistent approach to managing the acquisition of enterprise solutions as part of my SAF holy grail, and I feel a bit of optimism with regard to the design loop metaphor.
It is quite common in practice to bring in off-the-shelf application to cut development and maintenance costs. Arguably it will become more and more important trend, as applications and services are becoming commodities, especially with the proliferation of SaaS packages. But it is rarely the case when you don’t have to do anything with the application you’re buying in order to integrate with the rest of IT estate.
As a result, you’re starting with having at least two functional components, i.e. the application and some piece of technology that interfaces latter with everything you need it to talk to. Note, these are functional components. If you’re really lucky you will just plug the application into your strategic enterprise middleware platform (whatever it means), voilà. Although, I haven’t seen it working that way in practice.
From the design loop’s perspective things are looking as follows. There’s a couple or more functional components, one of which has a particular implementation with a particular flexibility margin. A set of system requirements describes a desired behaviour from the enterprise perspective. So you need to allocate system-wide requirements to functional components, keeping limitations of the application in mind. Having solved that equation, you’re getting functional requirements for other components. The only thing that is needed then is to come up with a candidate implementation and balance everything together to ensure soundness of the resulting physical architecture in light of budgetary and time constraints. Sounds like a plan to me!
Well, definitely not the end of the journey, but looks promising indeed, so I’m a bit excited. What do you feel? Does this design loop metaphor matches your experience? Any feedback is welcomed.