Integrating Design & Architecture

We're going to take a short break from Physics and dive back into IT - actually pretty soon we will see them intersect in our discussions - but for now we're going to expand on a topic I introduced on Dice.com last year: Integrated Design.

Many people view design work and architecture within IT as separate disciplines and perhaps as many different disciplines. It's my firm belief that all design-related effort (and architecture most definitely falls into that bucket) are related and contextual. The challenge of course is finding a way to integrate these activities - first from a process perspective and eventually through some sort of automation. One of the best ways to achieve this is through the development of an Integrated Solutions Framework.

One of the interesting characteristics of most Enterprise Architecture frameworks is that they are built atop meta-models. Those meta-models are in fact usually a 3NF (3rd normal form) relational data model (or ERD – entity relationship diagram). Having the models allows for the ability to deploy design artifacts to architecture repositories – it also provides a metadata framework that allows for reporting based upon the information resident within the designs. But most importantly perhaps, this illustrates how important it is to have a logical “mapping framework” for all information related to design. While using one of those frameworks within an actual software solution dedicated to architecture management is nice, it isn't necessary. One can recreate the logical framework as an organizational construct and still receive quite a number of benefits from it.

Here is a visual representation of what that standard framework might look like...

A prototypical framework for integrating design and architecture

In the following sections, I will provide potential benefits and explain the framework in more detail.

Benefits:

• This framework provides a clear linkage between specific elements of the architecture/design and requirements.
• This framework allows for consistent and logical descriptions of all solution elements across and within a given organization (and is scalable across organizations as well).
• This framework allows for management of all non-architecture designs alongside formal architecture deliverables. This is extremely important as in most organizations the majority of IT design is not captured as architecture (and in some organizations, none is).
• This framework can be used with no automation, some automation or total automation – it is also easily translatable to most EA frameworks.
• This framework can be integrated with / into any solution methodology and any standards management paradigm.

Levels (vertical):

1. Enterprise
2. Segment
3. Capability
4. Detail

Concepts (horizontal):

1. Design Activity or Description
2. Design Deliverable
3. Example/s

Definitions:

• Core / Holistic Architecture – The Holistic Architecture can exist potentially at several levels – it is roughly equivalent to an Enterprise Architecture (EA). Like an EA, the Holistic Architecture can encompass one or many domains and organizations. The main idea is that within some defined boundary the Holistic Architecture covers the comprehensive solution in question.

• Architecture Tier - An Architecture Tier tends to represent a logical layer within a holistic solution – for example this could be the shared Cloud Hosting environment that all other elements of the solution reside within. 

• Reference Architecture– A Reference Architecture can be a tier (more horizontal) or it could be a vertical segment (crossing tiers) within the larger Holistic solution. For example, a BPM workflow capability may stretch from to the infrastructure level to the User Interface and be considered the standard approach towards providing workflow capability to that organization (thus it is a vertical segment).  

• Core Capability – A capability is often associated with a slightly lower level of detail than the Reference Architecture. An example of this might be a BPMN design tool for business users to create their own workflow. Within the example Reference Architecture listed above, the design tool is located on one of several servers and provides its own unique interface that may not be generally available to the rest of the users in the presentation layer (for the BPM / workflow tool). Capability definition is used to facilitate requirements development and Use Case modeling. A Capability in this framework approach is roughly equivalent to a complex pattern.

• Complex Pattern – A Complex Pattern simply means that more than one pattern is being employed. Although allocation of scope to patterns is a somewhat subjective exercise, the goal within the paradigm presented here is provide as narrow of a pattern as possible in order to help drives specific decisions regarding solution allocation and configuration standards. The above Capability example represents a complex pattern as there are several distinct elements to the workflow mapping solution (each of which may involve different options to realize). 

• Simple Pattern – A Simple Pattern is the lowest level of architecture or design control; in other words this is where we specify the details for how the solution ought to work. For example, using the ongoing example, we might assign separate Simple Patterns for the Design UI approach for the modeling tool based upon whether it is being delivered to a PC or a mobile device. 

• An important consideration here is the notion that an organization can have more than one methodology; and in fact many organizations now have at least two, a traditional Waterfall approach and an Agile approach of some type. More complex organizations may have any number of methodologies to deal with; for management of Data Centers ITIL could be considered a methodology, for government Acquisition DoD 5000 is used, for data-centric projects many groups create approaches based upon DAMA’s DMBOK (Data Management Body of Knowledge) and so on. The design mapping described and illustrated below could be applied to any / all of those situations. 

copyright 2013, Stephen Lahanas