Enterprise Architecture – Do you have one?

Any organisation that does not maintain an Enterprise Architecture leaves itself open to all kinds of risks:

• Leaving strategic architectural decisions in the hands of vendors and consultants, when we should be taking ownership of these decisions, since we are responsible for the services we deliver to our customers
• A “Hodge-podge” of different solutions from Vendors X, Y and Z that do not integrate well and are not compatible
• Increased operational risk due to increased administrator overhead
• Increased cost in supporting these solutions due to different silos of skill-sets (increased headcount and training)

The Enterprise Architecture Domains:

• Application and Systems Integration – SOA, Business Portals, BPM, Business Rules, Service Delivery Management, User Management, Reporting Services and BI, Enterprise Service Bus, Business Application Service Providers, ETL, Enterprise Information Services, Service Governance and Partner Gateways
• Information Management – Knowledge, Information and Data Management, including the Five Pillars of Enterprise Information – Metadata, Master Data, Operational Data, Unstructured Data and Analytical Data
• Information Security – Unified Security, Network Security, Systems Security, Application Security, Data Security, Identity and Access Management and Security Virtualisation
• Network – WAN, LAN, Application Acceleration, Wireless Networks, Network Services and Network Virtualisation
• Platform – End User Clients, Servers, Storage, Backup/Recovery, Archive, Platform Services, Data Centers, Disaster Recovery and Platform Virtualisation
• Enterprise Systems Management – IT Governance and Reporting, IT Service Management and Element Management, including IT Process Automation, Infrastructure Optimisation, Business-to-IT alignment, Configuration Management, Consolidated Service Desk, Asset Management, End-to-End Application Management, Consolidated Event and Performance Management and Identity Management

How do we fix this?

Take the senior team leaders from the desktop, compute, network, security, storage, database, application and operations teams and they will form the “IT Architecture” team of your organisation.

First order of business:

• Where are we? What do we deploy? How do we deploy it?
• Where do we want to be?  What part of the services that we offer to our customers is clunky, inefficient, error-prone and expensive?
• How do we get there?  How long will it take?  What is the budget required?

This agreement can immediately be documented in a spreadsheet and will become version 1.0 of your Enterprise IT Architecture.  Now you need to spread the word – all stakeholders within your IT Division need to know what you are doing, why you are doing it and how you will get there.  This way you get buy-in, since you cannot do it yourself; it is always a team effort.

Do not forget to include our fledgling architecture in all Technology / Solution RFPs that we send to vendors.  Any current solutions that we have in the pipeline should also be assessed, maybe we can tweak and modify these solutions to match our architecture before they are deployed.

The preferred technologies that we decide to keep, should be ranked upon the following merits:

• Technology – Does the technology fit within our desired Architecture? Is it mature and stable, does it have the road-map that we desire?
• Professional Services – Does the Vendor/Partner have skilled resources available locally that can support us and our future projects?
• Maintenance and Support – Does the Vendor/Partner have support resources within your region/time-zone that can resolve our issues within the agreed SLA?
• Local Pool of Skills – Does our region have a pool of people with the skills required that we can hire at market rate?

A good architecture is actually a set of documents describing where we want to be, publishing it and spreading the word across the organisation.  This is about knowledge sharing and achieving buy-in from our peers.  It starts from the CIO down.