000

Guest Post by Russ Trpkovki

When a new project begins, I am often overwhelmed with the amount of information and number of decisions requiring my attention. I need to identify gaps in the current state architecture as well as think about future state technical capabilities. My analysis and decision making is usually done at a fast pace under high stress and lots of scrutiny from the program leadership.

Given the fluid nature of an early project, my expertise is often required in multiple discussions and white boarding sessions. One minute I need to focus on the web services that need to be developed as part of the future state architecture. The next, I may need to perform a deep dive into a fancy new rules engine required to meet a specific business need. At the end of day, I typically feel confident that I am making the right decisions and calling out the risks and issues.

Is the Architecture Complete?

In the back of my mind (and probably every architect’s mind), there is a lingering question of “Am I thinking of everything?” I reflect on the web services I identified during the white boarding session and feel uneasy about the lack testing tools for the new SOAP based web services.  Also, I am concerned about how the operations group will monitor the web services to trap exceptions and auto-heal the web services if one of the back end systems goes down during peak system activity.  Testing and monitoring tools are usually an afterthought when developing a new architecture, but no one wants to see a system go into production without the appropriate level of testing or operational monitoring in place.

Will the New Architecture Interoperate?

In addition to the different tools needed, I now turn my attention to figuring out how all the architecture components will work together. Will the new BPM component seamlessly connect to portlets being developed on the front end? Does the rules engine provide an out of the box adapter so the BPM can make remote calls to it as part of a workflow?

Architecture Assessment Frameworks

At PwC, we use two models, DEADONS+I and PARTS, to evaluate and design solutions.  They also are useful for assessing current state architectures. The DEADONS+I framework serves as an organizing framework to identify and evaluate the components and capabilities across both the solution and technical architecture domains. The PARTS Framework is used to ensure the architecture components come together in one cohesive, holistic design when assembled together as part of a system.

Although the frameworks seem relatively simple and intuitive, DEADONS+I and PARTS serve two very important functions when thinking about architecture:

• Helps decompose a complex problem into a set of comprehensive, manageable pieces in order to perform analysis, identify gaps and develop future solutions
• Creates a common language that architects can use to communicate architectural concepts to one another

You can think of DEADONS+I as the checklist to make sure you are thinking about everything, and PARTS as the means of bridging the gap from architecture to design to ensure the architecture components fit together.

DEADONS+I and PARTS work best when used together to get complete coverage for either an analysis of an implemented solution or as a framework for specifying a new design. PARTS guides the collection of data necessary to characterize quality within the architecture categories of DEADONS; however, not all PARTS apply to all DEADONS architecture domains. In a follow-up, I will explain how to use a combined matrix to evaluate and design solutions.

I would love your reactions to these frameworks and any tips you have for assessing architectures.

cc licensed flickr photo shared by USACE European District

000