IT Architecture Review: The Basics, The Approach, The Outcome

I wanted to write something from the Enterprise Architecture side on my blog for some time. In this blog post I am trying to cover the Architecture Review for a given Enterprise.I will start with some basics on this topic.

What’s Architecture?

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

  • ISO/IEC 42010:2007

A formal description of a system, or a detailed plan of the system at component level to guide its implementation.

  • TOGAF

The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

  • TOGAF

Why Review your IT Architecture?

 

  • IT architecture is a key component in supporting business goals and objectives:
  •  Foundation for developing large, complex, distributed systems environment;
  • Manage and control complexity in system deployment;
  • Basis for determining software and hardware decisions
  • Defines the overall IT goals, organization and system components needed to support long-term business requirements
  • Identify gaps and areas for concern or improvement
  • Optimize return on IT /IS investment
  • To see if your enterprise is ready to take the next business challenge or not with the current infrastructure that you have? What needs to change and why?
  • Are there chances of efficiency in the current infrastructure?

Who do you need to do this Architectural Review for your Enterprise? You need an Enterprise Architect. But what do you expect them to do?

Things That Architects Don’t Do

  • Process compliance – that’s project office
  • Estimates – that’s service owners
  • Hardware specifications – that’s Engineering
  • Software specifications – that’s Developers
  • Requirement gathering – that’s Business Analysts
  • Process description – that’s Business Analysts
  • Windows – that’s Building Maintenance

Things That Architects Can Do

Plan technology direction and set technology standards

  • Help you figure out which technologies you should support.

Review plans, designs and purchases

  • Assess how well a plan aligns with current direction and desired future positions.

Identify opportunities to reuse components and services.

  • Leverage enterprise contracts and license agreements.
  • Integrate shared services where they might be cost-effective.

Review business organization and business processes

  • Technical Architecture:  align your technology plan with enterprise goals, business plans and business processes.
  • Enterprise Architecture: align your business plans, business process and technology plan with your enterprise goals.

Benefits of Architecture Review

  • Identifying potential risks in the proposed architecture
  • Assessing quality attributes (for example, scalability, performance)
  • Identifying opportunities for reuse of artifacts and components
  • Promoting good architecture design and evaluation practices
  • Reducing project cost caused by undetected design problems
  • Capturing the rationale for important design decisions
  • Uncovering problems and conflicts in requirements
  • Conforming to organization’s quality assurance process
  • Assisting stakeholders in negotiating conflicting requirements
  • Partitioning architectural design responsibilities
  • Identifying skills required to implement the proposed architecture
  • Improving architecture documentation quality
  • Facilitating clear articulation of nonfunctional requirements
  • Opening new communication channels among stakeholders

Source : Survey of benefits perceived from systems architecture among 86 responding organizations, from Software Architecture Review: The State of Practice by Muhammad Ali Babar, Lero—the Irish Software Engineering Research Centre and Ian Gorton, Pacific Northwest National Laboratory, IEEE Computer July 2009 © IEEE 2009

We perform architecture reviews to ensure:

  • The architecture of a system is documented.
  • It provides a coherent description of the system.
  • It is conformant to Customer principles, standards and plans.
  • It is compatible with the legacy technical landscape.
  • That the chosen technology and design is likely to achieve the project’s goals and objectives.

How to Conduct IT Architecture Reviews

  • Define business goals and objectives
    • Identify existing IT and systems infrastructure environment:
      • The structure and organization of IT /IS in supporting business goals
      • The architectural framework ( layers) for developing and connecting system components
  • Review and Identify gaps between architecture characteristics / attributes and business requirements

What to review and assess

  • Logical -functional requirements of IT architecture
    • Abstraction & Encapsulation
    • Information hiding
    • Separation
    • Modularization
  • Process –abilities of the system that can be measured
    • Flexibility
    • Security
    • Scalability
    • Performance
    • Reliability
    • Availability
    • Maintainability
  • Infrastructure –Physical infrastructure and system components

Some of the other non-functional requirements

  • Scalability
  • Reliability
  • Flexibility
  • Performance
  • Manageability

Performing the IT Architecture Review

Areas to consider for assessment: Information Resource Planning, Business Continuity Planning, Architecture Development, and Security.

Outcome of an Architectural Review

A clear defined outcome is very important for an Architectural Review, you need to identify in beginning as what are the deliverables for the project. What is the project sponsor looking for, how is he going to use the information provided in the Architecture Review. Few of the documents that I generally release as part of my architectural review are…

  • A detailed Architecture Review Document: This contains very detailed information on the points observed from the system, what’s the recommendations and mitigation. Generally this document is consumed by the teams who are going to look at doing those changes.
  • An Executive document describing and mapping the business goals with the technical analysis and a future roadmap for the Infrastructure. This document is intended for CIO or the IT head.
  • A Summary presentation.

Now the next question is how is it different when the environment is Virtualized or using Private Cloud or has moved to Public Cloud , what to do in this scenario. This is a topic for another blog article till then stay tuned ……

Note: Some of the information posted here has been taken from EA literature and have been given due references, if you think some references are missed let me know and I will add it.

One thought on “IT Architecture Review: The Basics, The Approach, The Outcome

  1. Pingback: Newsletter: May 4, 2014 | Notes from MWhite

Leave a Reply

Your email address will not be published. Required fields are marked *

*


− two = 6