One common problem I see in the IT industry is the qualification of IT decisions. I talk to architects from all around the world and hear a lot of creative and innovate ways of solving problems. More often than not, what I don’t hear is more concerning.
When I have asked:
- Why did we approach the problem in this manner?
- How does this align to the business?
- Does this fulfill the business, functional and non-functional requirements
- Why is this the optimal architecture?
Obviously there are a lot of other questions, but to keep this concise above are some sample questions. The last question is particularly interesting. I have heard a broad range of fluffy answers such as: “trust me, I know what I am doing”, “I have been doing this for 20 years, I know how to do this”, “I am the expert of [X]”. All of these responses may be completely true but doesn’t quantify the solution. It doesn’t demonstrate that there was a process or a clear level of due diligence that was performed.
Personally, I think this is what gets architects in trouble. We may being quantifying this all in our heads and maybe very good at that, but if our business and IT stakeholders do not see that is can send the wrong impression.
Generally I would recommend against doing all of this mentally. There are methods that we can use to keep ourselves in check to make sure we are thinking of all the permutations. This is called the architecture Qualification Method (AQM). In this post I will give you a high level overview of this method.
The Architecture Qualification Method (AQM)
AQM is a pragmatic way of aligning to business architecture and ultimately fully qualifying our architecture decisions. This is done through going through a methodology and set of tools that aid architects in:
- Using a method of capturing quality attributes for the enterprise
- Mechanisms to capture definitions of quality attributes that can be tailored to your organization
- Intelligence that allows for the classification and variability of quality attributes
- Providing a framework to rationalize them to the solution
- A way to govern how architectures are classified and rationalized throughout the organization
AQM directly solves issues with complexity and the understanding of architectures. Shown below is an example of just a small subset of inputs in to the architecture decision making process. As you can see there is inputs from all sides.
The goals in which AQM is to meant to solve is:
- Provide a way to capture architecture analysis in a repeatable way
- Qualify the architecture quality attributes
- Reduce complexity and confusion in building out solution architectures
- Create a classification framework that allows for the orchestration of architecture standards and design patterns
- Ease governance through the qualification of usage of standards and design patterns
- Make architecture re-use proactive by reduction of complexity
Architectures have multiple cross cutting concerns that can be difficult to understand and quantify. As I mentioned this is just a small sampling of concerns,
I hear from a lot of architects that they have a lot of trouble trying to fully qualify how they make architecture decisions. When I say I qualify, what I mean by that is the process for designing a solution that
How does AQM do this and how is it different?
AQM takes a structured approach to solving architecture problems. This is different from other solutions because it provides a way for enterprises to define there own measurements based on the business they are in. For example:
The above example is meant to illustrate the different criticalities of these industries. Take the information with a grain of slat as I am not an expert in manufacturing. The point is that all industries are different and all companies have slightly different ways of running their business which can have a dramatic impact on how we create architectures. This is further illustrated in Jeanne Ross book Enterprise Architecture as Strategy when she compares the differences two companies in the same industry like FedEx and UPS and show vast differences in the IT systems that support their business.
What we get when we look at this all up is the following:
Providing a way to have full traceability is a core tenet of the AQM. It is absolutely critical to be able to not only justify our decisions but to quantify and qualify them. They only way to do that is to align our decisions to business imperatives. At the end of the day, the bottom line.
The AQM is used with the following components that are illustrated above:
- Process – Specific to the AQM, this provides the integration into existing processes and it’s own unique process for executing the AQM.
- Classification System – The classification system has two aspects that it covers:
- Defining quality attributes into the terminology and the specific taxonomies that are well understood by your enterprise. The unfortunate reality is we all have various definitions of architecture terms.
- Creating classifications, properties and thresholds on quality attributes. This is one of the most important aspects of AQM. This mechanism provides a way to fully qualify quality attributes through properly defining what they mean to your enterprise. Through these classifications, properties and thresholds it is what enables AQM to both quantify and qualify architectures.
- Asset and Pattern Mapping Matrix – Once a classification system is created through AQM you can now start to correlate that with real things. Real things meaning your design patterns, standards, policies, existing IT assets (system or application). By doing so you can have a systematic way of prescribing what patterns to use for solutions. Subsequently, automating decision making, making it traceable and easing governance. An example of this is a common scenario I run into. Let’s say you organization has standards on a set of technologies for communications. Let’s say those standards are: FTP, SFTP, Web Services, CIFS/SMB, Connect Direct and SQL Server Integration Services (SSIS). Since these are all in the standards list developers or architects may not choose the optimal one for a variety of reason which could include: costs factors, complexity, lack of understanding of the technology or personal biases. So in the scenario the architect chooses FTP because it is cheap and faster to implement. The problem is that the drivers for the solution call for the transactions to be highly secure and have a high level of resiliency. FTP isn’t the choice here. So with AQM we can put qualifiers on these standards to show in what circumstances should you use each standard. This is applied to all of the architecture quality attributes (architecture –ilities, such as: scalability, security, reliability, interoperability, etc.)
- Qualification Tool – The tool comes in when the architect wants to make build out a solution. As mentioned in the scenario above, the tool provides a way to put all the pieces together in an easy way. All of the complexity is removed from the architect so he/she can focus on creating a solution rather than thumbing though a thousand standards pages to ultimately find something that may or may not be useful.
So how do I use AQM?
It is one thing to define a methodology but it is an entirely different to make it actionable. below is how the AQM is rationalized and immediately actionable and pragmatic:
- Excel based templates that can be used by nearly every architect day 1
- Integration into an architecture meta-data repository
- Standard process definitions in SharePoint
Below are screen captures of various aspects of the AQM. Data hasn’t been populated in these for very specific purposes. However, in the sample information is populated in the classification matrix to show some sample values. This is very simplistic and just show what kind of data would be represented. In a real world implementation the repository would handle a great deal of this by joining multiple relationships with information and classifiers of a quality attribute. The spreadsheet is a viewing mechanism.
We took a very high-level look at the AQM and showed the purpose, methods and tools associated with it. Through this method you can expect a greater level of of accuracy and quality of architecture decision making.
