Book Pick: Lean EA Engineering

Phased Yet Lean Engineering Processes
Excerpt from Enterprise Architecture Fundamentals:


Beyond the open-ended list of labels given by methodologies to boxes and arrows (e.g., requirements, specifications, design, high level, low level, detailed), the question is basically the same: how many steps and intermediate outcomes are necessary between the inception of a project and its completion? In a lean, just-in-time, and frictionless pure software realm, the answer would be none — a scenario that would minimize the waste of time and/or resources. Assuming projects are free of organizational, functional, or technical dependencies, developments could be carried out directly from processes to applications through iterations combining requirements, development and tests, and deployment (figure 13-2a). Decision-making (cf. chapter 10) could also be streamlined between enterprise workshop (for business objectives and systems constraints), applications workshop (for users’ requirements), and systems workshop (for deployment).

Figure 13-2. Direct (solid line) & Phased (dashed line) Development Models

That straightforward development model is not limited to stand-alone applica- tions. It can also pertain to applications relying on systems functions, providing that requirements are stable — a condition that can be expected if functions are supposed to be shared across the architecture. In that case, EA frameworks (cf. chapter 5) should secure easy access to all relevant resources, preferably through agreed-upon models (cf. chapter 7). Such a development model, typical of business-driven require- ments, can also be applied to architecture-driven projects; for instance, to Quality of service (QoS) developments.

By contrast, a phased development model (figure 13-2b) characterizes architecture-driven projects, with intermediate outcomes or milestones used to man- age organizational, functional, or engineering dependencies. Assuming an architecture framework, development teams would collaborate through the exchange of models: descriptive or Computation independent (from the enterprise workshop), prescriptive or Platform independent (from the domains workshop), and technical or Platform specific (from the applications workshop). These issues will be detailed in the next chapter.


(From Chapter 13)

%d bloggers like this: