The main objective of The Good enough Architecture MEthodology is to create a good enough ground for an IT solution (one solution or a whole IT portfolio) by using methods and best practices for gathering and analysing the adequate requirements that enable the design, development and establishment of a good enough architecture.

The methodology puts all the components and deliverables in the context required for the architecture that in whole should fulfill the requirements. The work is done through agile design and development of the required building blocks, that all together combine a working IT solution or a whole IT environment.

Architectural aspects

The architectural aspects describe each layer of the architecture, by definition of the major deliverables through visual presentations, written descriptions and samples. These descriptions and samples are mostly provided with details such as input, output and execution requirements at a high-level that for some cases have been drilled down with more details at low-level (executable codes and models). These requirements define the capabilities for each aspect (e.g. layer) of the architecture and its building blocks that are required for developing a solid architecture for the desired solution.

The architecture is defined, designed and developed from these six aspects:

• Business Architecture
• Application Architecture
• Data Architecture
• Infrastructure Architecture
• Security Architecture
• Governance Architecture

Architectural perspectives

The architectural perspectives define and visualize the four major maturity levels of the architecture:

• Contextual architecture
• Conceptual architecture
• Logical architecture
• Physical architecture

Answering to the architectural questions

The Good enough Architecture MEthodology is a more practical methodology than a theoretical and in difference with other methods and frameworks, it describes not only "What" should be done and created, but also:

• How it should be done and how the architecture and its components will behave
• Where everything should be done and where they should be applied
• When they are applicable and in which phase of the wanted To-Be
• Who should do what and who will be using or get affected by what
• Why something has to be done and why it should be done as above

As additional help and guidelines, the methodology also includes samples of the final deliverables, and a set of available templates and patterns. These will enable you to define, design and visualize the required building blocks to create the architecture that is adequate for the purpose and good enough.

The methodology has been developed in real-life projects and assignments by several architects. The methodology and its concrete, useful and applicable deliverables have fulfilled the requirements in these efforts on an extraordinary complete manner and led the projects and the efforts to successful and functional solutions and improvements in their IT city plans.

When is it 'good enough'

Some of the preconditions what is a "good enough architecture" are:

• Done previously by architects in real-life efforts
• Achieved goals from the client's perspectives
• Concrete and ready to implement concepts or codes
• Scalable architecture, regarding logical and physical components
• Flexible but yet secured and robust solutions
• Simple and realizable, even for complex needs
• Fulfills the known business needs for the short term
• Builds the solid ground for the assumed business needs for the long term
• Covers all aspects of the architecture from business to infrastructure
• And more

External links

• Introduction to the Good enough Architecture MEthodology, The GAME introduction