To be a software architect means that you must learn to think like an architect - in particular, a distributed systems architect.
This is a substantial paradigm shift from thinking like an individual software developer writing one program. In this world of increasingly distributed IT systems, much of what you learned in your previous training an naively mislead you.
In order to go to war, you need to commit to a new mindset and a ruthless pursuit of architectural knowledge. Ignorance is our enemy, and knowledge is power on the architectural battlefield. We must erase mistaken assumptions and help you think about systems with much greater clarity, so that you can reason about the complex issues involved.


Unless you program telecommunications systems, video games, mainframe operating systems, or rigorously inspected software (e.g., CMM Level 5), almost every piece of software you will ever encounter is riddled with defects and, at least in theory, doesn't really work.
It only appears to work - until an unexpected combination of inputs sends it crashing down. That is a very hard truth to accept, but experienced architects know it to be the case. In commercial software, nothing is real. If you don't believe this, invite a non-computer user to experiment with your system. It won't take long for them to lock up one or more applications and possibly invoke the Blue Screen of Death. In order to cope with this uncertain terrain, you need to begin thinking about software as inherently unreliable, defect ridden, and likely to fail unexpectedly.
In addition, you need to confront numerous issues regarding distributed computing that aren't taught in most schools or training courses.
We have many things to learn and unlearn as we go to war. We begin by recognizing a key paradigm shift that leads to a deeper understanding of distributed computing and its pervasive consequences.


The essence of the paradigm shift revolves around system assumptions. Traditional system assumptions are geared toward non-distributed systems - for example, departmental data processing systems. Under these assumptions, we assume that the system comprises a centrally managed application where the majority of processing is local, the communications are predictable, and the global states are readily observable.
We further assume that the hardware/software suite is stable and homogeneous and fails infrequently and absolutely: Either the system is up or the system is down.
Traditional system assumptions are the basis for the vast majority of software methodology and software engineering. Traditional system assumptions are adequate for a world of isolated von Neumann machines (i.e., sequential processors) and dedicated terminals. The traditional assumptions are analogous to Newton's laws of physics in that they are reasonable models of objects that are changing slowly with respect to the speed of light.


After many years of brutal lessons learned, enterprise software development is moving out of the heroic programming dark ages and into an industrial-strength architecture revolution.
The key is architecture-centered development, and most software experts agree that for complex systems nothing else works. In this section we will explain the architecture-centered development process in some detail. But first, let's see why this software revolution is an inevitable necessity in enterprise development organizations.


Here is a typical development scenario that is occurring in many enterprise software organizations today. The enterprise needs a new software system.
The target system is a replacement or consolidation of existing systems which do not support necessary changes to business processes.
A project manager is appointed and a development team formed. The development team is a mixed group with some current and legacy skills (often with the balance toward legacy). The project manager studies potential approaches and concludes that "object-oriented" (or other current buzzword) is the only paradigm that makes sense, given readily available, commercial technologies. In other words, the manager is led to believe that buzzword technology will make system success easy. Vendors encourage this illusion by claiming that their products can remake ordinary developers into programming stars. So the manager makes technology commitments and puts the development team through a product-specific programming course. After that, nothing seems to happen. The team struggles to analyze, design, and program the system, without much measurable progress. The manager grows increasingly frustrated and worried, as the project schedule slips into political trouble with upper management and end users.
Statistically, the manager was doomed, almost from the start. According to reliable surveys, the brutal reality is that one-third of all corporate development projects are cancelled. Five out of six projects are considered unsuccessful and unable to deliver desired features. Even average projects have schedule and budget overruns nearly double the original project estimates.


Heroic programmers can help a project to avoid short-term consequences, by delivering software that appears to meet end-user needs.
Now that user interfaces are relatively easy to implement, the illusion of working software is increasingly easy to demonstrate.
However, the complexities of developing a system that accommodates change is another matter. Heroic programmers are usually too close to the software problem to consider these longer-term consequences. Heroic programmers often fail to see the bigger dragon.
With today's complex programming notations and distributed system capabilities (e.g., intranet, N-tier), it is widely understood that software modules are unmaintainable, except by the original programmer. Averaging at 30% annually developer turnover can quickly obsolesce an undocumented, heroically programmed system into an unmanageable stovepipe system.
We believe that good programmers are absolutely necessary, but not sufficient, to ensure system success. Even in the most qualified of hands, the available program design methods, software tools, and computing technologies are surprisingly inadequate, compared to today's enterprise systemchallenges. Managing change and complexity requires much more than raw programming talent in order to realize a successful and maintainable system.Solutions to today's enterprise development challenges are possible through architecture-centered development--in other words, through working smarter, not harder, by doing software right.


Solving complex problems with teams of people requires planning. For enterprise software systems, some of the most important planning is highly technical (i.e., planning system architecture). Planning generates artifacts, but planning (as an activity) is much more important than project management plans, the typical artifacts. By this, we mean that document-driven process is not recommended because its priorities focus on paper artifacts, whereas the real product of any software development project is software. Instead, we view planning in a broader context, with multiple levels of formality and technical detail.
For example, architecting is planning, and so are requirements analysis, design modeling, and generating plans.
The level of formality should be tied to the longer-term usefulness of the documentation. In architecture-centered development, planning is pragmatic. Project plans and design models are throwaway documentation because their accuracy is short lived. Once a plan or specification is out of date, it is essentially useless. For example, source-code changes can quickly obsolesce design models.

In addition software methods and standards should be treated as guidelines, not mandates.
Project teams are encouraged to think for themselves and tailor the process to meet the project's needs. Pragmatics is a fundamental principle of software modeling: for requirements, architecture, and design. Every model has a purpose and focus, suppressing unimportant details.
Models should document important decisions, based upon project assumptions and priorities. Deciding what's important is an essential decision skill that is part of being a competent architect.

---

• Run Away Back to Mama
• Basic Level
• Drill Sergeant
• Navy SEAL
• Special Advisor
• Commander-in-Chief
• Secret Agent
• I Spy

---