Model-Driven Enterprise and Software Architecture

The Architecture Problem

Effective architecture is a key enabler for an enterprise or software system. Inappropriate architecture can severely compromise enterprise goals. Yet odds are that your enterprise and software architecture is not meeting your goals as well as you would like.

For both enterprise and software systems, there is an interaction between three evolving factors: the goals, needs, and problems of the business; the actual deployed  system(s) or applications(s) meeting or failing to meet those needs; and the applicable architecture styles, patterns, and tools. The architecture plays a key role in keeping these factors balanced. It helps frame possible solutions to problems and raise questions about high-risk issues. It forms one key input into building and testing. And helps evaluate alternative approaches and glean new lessons learned.

Building and evolving effective architectures at the enterprise level is a difficult proposition. It typically involves a witch's brew of diverse organizations, varied business and technology stakeholders whose goals and strategies are not clear or well aligned, and long-lived heterogeneous systems and applications of different granularity running on a mix of technical platforms. There are often ingrained problems with ownership and duplication of processing and data, new technologies either shoe-horned into an inadequate infrastructure or entirely overlooked, poorly understood systems and dependencies, and mysterious business processes.

Systemic "blind spots" strike with depressing regularity, often directly at the gaps between business and technology, between architectures and implementations, betweeh architecture and operations, logical architectures and platform realizations, and ivory-tower architecture principles versus shop-floor reality.

Building an effective software architecture for an end-user application or technology infrastructure brings slightly different but related problems. High-impact aspects of the system have to be made visible through lots of extraneous details, and  evaluated carefully in the context of goals and needs. Those functional and non-functional properties of the system that represent key risk areas must be consciously addressed. Architecture styles, governing the nature of the components and the properties of the connectors between them, need to be sufficiently clear in the implementation or in a separate formal or informal architecture description.