# 2 - System Architecture

Every system built by humans has an architecture. Systems such as cars, airplanes, mobile phone software are defined by a few key decisions that are made early in each program’s lifecycle. For example, early decisions in automobiles development, such as the mounting of the engine, drive a host of downstream decisions. Choosing to mount an engine transversely in a car has implications for the modularizing of the engine, gearbox, and drivetrain, as well as for the suspension and the passager compartment. The architecture of a system conveys a great deal about how the product is organized.
In the design of complex systems, many of these early architectural decisions are made without full knowledge of the system’s scope. These early decision have enormous impact on the eventual design. They constrain the envelope of performance, they retract potential manufacturing sites, and so forth. As an example of gathering downstream information for upstream consumption, the overall width of some products is constraint to be less than the column separation at the manufacturing site. In this case the width constraint is obvious to the development team and was not uncertain or hidden, but it is one of the main variables in the productivity equation in the product development.
The central assertion here is that these early decisions can be analyzed and treated. Despite uncertainty around scope, even without knowing the detailed design of components, the architecture of the systems merits scrutiny. Architecting a system is a soft process, a composite of science and art. In no way this can or should be a linear process that result in optimal solution. The main point here is that structured activity is better than unstructured creativity.
Architectural wisdom is often an understanding of the tradeoffs between decisions. Making architectural decisions is rarely as simple as encoding an architecture as a decision-making problem and then choosing the best architecture according to a single metric. Rather, architectural decisions often involve understanding the main tradeoffs among decision, evaluating the weighting between metrics in view of the solutions they lead to, and understanding the coupling among decisions. 

System architecture influences many business outcomes and has long-term consequences. Architecture is a business decision and it should follow from your business strategy. Rather than leaving it to some specialists, you’re better off assembling a cross-functional team of experts to look at the possibilities from several angles. Executing an architecture may be a technical matter, but planning one goes well beyond the Engineering department.

Comments

Post a Comment

Popular posts from this blog

# 11 - Model-Based Systems Engineering (MBSE)

The best way to understand the MBSE approach is to begin by understanding the alternative: what modeling partitioners call the document-based approach to engineering (and what nonpractitioners call "the way we have always done things!"). With the document-based approach, engineers manually generate some subset of the following artifacts: concept of operations (ConOps) documents, requirements specifications, requirements traceability and verification matrices, interface definition documents, systems design specifications and speciality engineering analysis such as analyses of reliability, FMEA, etc. Document-based systems engineers produce these artifacts in a form of a disjoint set of text documents, spreadsheet, diagrams, presentations (and configuration-manage them in a disjoint set of repositories). The document-based approach is expensive. More precisely, it's more expensive than it needs to be; you incur a significant percentage of total life cycle cost maintaining t...
Read more

# 10 - Principles of Dynamic Work Design

Image
Consider a well-known example of work and organizational design, Toyota’s Andon cord. In the Toyota scheme, a worker noticing such an issue is supposed to pull what’s known as the Andon cord (or push a button) to stop the production line and fix the problem. While the management literature has correctly highlighted the importance of allowing employees to stop the line, what happens after the cord is pulled might be more important. When one operator on the factory floor is struggling to complete a task in the allotted time, and so hit a yellow button, causing an alarm to sound and a light to flash. Within seconds, the line’s supervisor arrived and assisted the operator in resolving the issue that was preventing him from following the prescribed process. In less than a minute, the operator, now able to hit his target, returned to his normal routine, and the supervisor went back to other activities. A visual of this process can be seen below: What, from a work design perspective, happened...
Read more

# 12 - MOEs, MOPs and TPMs

Let's start by defining these acronyms: - MOEs: Measures Of Effectiveness - MOPs: Measures Of Performance - TPMs: Technical Performance Mesures Following a recent discussion on this topic, I've come to realize that there is a lot of confusion around these concepts, so let's try to bring some clarification! MOEs, which are stated from the acquirer (customer/user) viewpoint, are the acquirer's key indicators of achiving the needs for performance, suitability and affordability across the life cycle. The MOEs are used to validate the system at each stage of the design process and provide insight into some of the more subjective qualities desired by the acquirer that are not, or can not, be captured by hard requirements. Many of the "ilities" are used in MOEs where, for example, it may be very difficult to generate a shall statement on operability, but operability nevertheless remains an important characteristic. MOPs measure attributes considered as important to e...
Read more