How to Assess Your Technical Architecture

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

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

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0
  • Not a bad approach to structure your approach and thoughts. However, I can see how the two frameworks would vary at different organizations though, based on priorities and EA principles. I would suggest the PARTS Framework is not just “measures”, but in fact are non-functional requirements. These characteristics can be legitimately for different solutions based on business criticality and need… something which absolutely needs to be determined for the target architecture. Also, you may want to add “Recoverability” to the list…

    • Anonymous


      Thanks for the feedback.

      I agree. The frameworks can and should be modified to adjust to the EA principles and task at hand. For example, if an organization wanted to focus on service design, I would identity measures to include service discoverability, composability, etc.

      As far as recoverability, I know the data architecture within DEADONS+I defines the tools, strategy, and services to address data backup and recovery of information assets. Also, the operations architecture covers controls and support services such as event management, system monitoring and, troubleshooting. Is that what you had in mind?

      Russ Trpkovski

  • Ted Corbett

    I like this approach, very sensible yet leaves room for flexibility it appears… you know what I also like to watch out for - that has to be addressed in architecture? It’s the shadow IT architecture components (aka business units/depts that got tired of waiting for what they want and were able to fund/put in something that isn’t “part” of ITs support domain) these are still “in” the current state, these “solutions” can be insidious, esp. in large enterprises. Accounting for these, architecturally, is key to include, while it can also take quite a bit of interviewing and questions to flush out - as discussions can be “uncomfortable” for client groups.

  • Pingback: 10 Ways to be More Agile — CIO Dashboard()

  • Pingback: Architecture Technical Requirements | Great Architecture Fan()