IT Transformation – Part 4 – The Target Architecture

This is part 4 of the Information Technology Transformation series, defining the reference “Target Architecture”.  This involves collecting Business Requirements, translating them into “Architectural” technical requirements, creating the “Target Architecture” and then sharing it via summarised Architecture Posters.

This is a six part series describing Information Technology Transformation within a struggling company:

The Target Architecture must meet the business requirements of your customers and you need to document it in the most efficient manner possible.

Target_Architecture

Collecting Business Requirements

When you talk to your Customers, they use “Business Language” to describe their requirements.  They do not care about the technology you use, they care about the services you deliver.  You will repeatedly hear about standard business requirements such as “Decreased Time to Market”, “Maintain Same Operational Headcount”, “Increased Revenues”, “Decreased Operational Costs”, “Increased Availability of Services”.  The trick is to translate these into “Architectural” requirements that can be used in the technical arena.

For example, “Decreased Time to Market”, “Decreased Operational Costs” and “Maintain Same Operational Headcount” could be translated into the following “Architectural” Requirements:

  • Self-Service Catalog with Automated Workflows
  • Public/Private/Hybrid Cloud Services
  • Cloud Automation and Orchestration
  • Automated IT Service Management

Another example, “Increased Availability of Services” could be translated to:

  • Five 9’s of availability for Business Critical Applications
  • Three 9’s of availability for Non-Critical Applications
  • Disaster Recovery Automation for Business Critical Applications

Technology Brainstorming

You will already have met with the technology owners of each silo during the “Baseline” process.  Now instead of focusing on where you are, you have to talk about where you want to be.  Each silo owner will have very strong opinions on what the future will look like, but as Chief Architect you need to ensure that each silo aligns with the big picture and that the fundamental business requirements are being met.  These discussions will provide the first draft of the “Target Architecture” that will then evolve to the “approved” Target Architecture.  Be patient, this process takes time, because every stakeholder must agree for the IT Division to succeed as a team.

One of my favourite Nutanix quotes: “Complex is competent, simple is genius” holds true for every architectural decision.  Do not implement technology for technology’s sake, it must exist for a reason.

Defining and Documenting the Target Architecture

I have been in the design and architecture business for 10 years now, and I got used to delivering lengthy tomes that when printed, looked impressive and weighty.  My VCDX certification and mentoring journey has forced me to rethink architecture design and documentation.  Where my standard enterprise architecture was typically 500 pages, I now believe using a spreadsheet is enough to document an architecture (when complemented with the “Architecture Posters” below).  The reason is that long, detailed documents are rarely read and whilst impressive, do not really add value.

Brevity is your friend.  By providing a reference architecture in a spreadsheet, this is enough to get the job done and increases the probability of your audience reading and understanding what you are trying to achieve.

Remember, the Enterprise-wide Architecture is the Logical Design, it documents functional modules and how they interact across every technical silo, you should not be specifying the physical design components (eg. Vendor name, model).

Also, a summarised version of the “Target Architecture” spreadsheet can easily be added to your company’s RFP process to ensure that Vendors will comply with your vision before responding to an RFP, saving time on both sides.  You can also add your physical design decisions to this spreadsheet to further aid Vendors in responding with the correct solutions (eg. must support vSphere 5.5, must integrate with IBM WebSphere MQ).

As with the “Baseline”, your target architecture needs to cover the following technology areas:

  • Application
  • System Integration and Middleware
  • Information Management
  • Information Security
  • Compute
  • Network
  • Storage
  • Backup / Recovery / Archive
  • Business Continuity and Disaster Recovery
  • Cloud Automation and Orchestration (CMP)
  • End User Computing / Virtual Desktop Infrastructure
  • Management and Monitoring

Here is an example of an Architecture Spreadsheet.

Architecture Posters

“A picture tells a thousand  words.”  Similar to the “Baseline”, this is also true for the Target Architecture, it transforms dry, boring and complicated into interesting.  So it is very important to summarise the major areas of the IT Division into “A0” size laminated posters to be positioned in the meeting rooms and offices of the company.  Posters draw the eye and are interesting to people and should be used as a tool to spread your message: “We know where we are, we know where we want to be and we know how to get there!”

You should have at least one summary Target Architecture poster:

  • “Target” IT Services Architecture – Application, System Integration, Compute, Network, Storage, Backup / Recovery / Archive, BC / DR, Security, Cloud Management Platform, EUC, Management and Monitoring, etc.

Here is an example of an Architecture Poster.

Review Cycle

These documents need to be updated yearly, otherwise they become outdated and lose their value.  This is true for all documents in the Baseline, Target Architecture and 5 Year Strategy.

Other Resources

Published by

vcdx133

Chief Enterprise Architect and Strategist, 4xVCDX#133, NPX#8, DECM-EA.