Total architecture defines the structure and organization of business processes, people, information, and systems. Today's business processes and information systems have become so hopelessly intertwined that it is no longer possible to design one without altering the other: they have to be designed together. This design also defines the structure and organization of the people and information involved in the process.

Total architecture extends the principles of scenario-based design to encompass entire business processes. It builds upon Barry Boehm’s spiral methodologies and leverages UML to implement the IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.

This site is intended to serve as a focal point for total architecture, both theory and practice. 

Service-oriented architectures are a particular style of distributed system architecture in which functionality is partitioned into components that are referred to as services. While early SOA work focused on the componenization aspects, more recent work focuses on mediating the interactions between service consumers and providers and on managing the complexity of large numbers of services at both design time and run time. The following materials augment the SOA information contained in the total architecture books.

Building and operation a service-oriented architecture requires discipline both at design time and run time.

The linked SOA and Governance video and accompanying SOA Governance Essentials presentation provides overviews of this topic.

It is important to determine whether a planned design will actually perform to the required level. Making such a determination generally requires performance benchmarks for the individual components and services that comprise the design. Creating and interpreting benchmarks can be tricky.

The linked Performance Benchmark Fundamentals whitepaper and accompanying Performance Benchmark Fundamentals presentation provide overviews of the best practices for creating benchmarks. The spreadsheet referenced in the whitepaper can be found here.

SOA and BPM projects generally involve two or more systems, which almost always means two or more organizations. The presence of multiple organizations presents challenges that must be addressed in order for projects to succeed.

SOA presents another challenge as well. The project team that identifies a service opportunity generally has neither the time or the resources to explore other potential uses of the service. From an organizational perspective, who is going to provide that additional perspective? Without it, the likelihood of creating a reusable service (and thus achieving the ROI) is vanishingly small.

The linked Organizational and Management Issues Vital to SOA and BPM Success presentation provides an overview of these challenges and their solutions.