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
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.
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.