Can Architecture Frameworks fill the gaps between ISO Accreditations?

Anyone who's been involved with developing business change will have noticed the proliferation of "Architecture Frameworks" (AFs).     Coming from an IT background, it's easy to mistake the concept of an AF with a Technology Framework or IT Infrastructure.  So what is an AF?

Simply put, an AF is a description of how your business works.  Think of it as a suite of documents describing what you do, and how you do it.    

Back in the old days, in order to satisfy your clients and prospective business partners that you were legitimate and rigorous, you'd perform an ISO9001 process and audit.   However ISO9001 (boiled down) seems to say "All your processes, if documented, are in this document".   ISO9001 was great for service-oriented businesses, but started to break down where customer-specific processes were required.  Ultimately you had to have a section which read (effectively)  "... and at this point, we do whatever the customer wants.", which is carte blanche to do whatever, and not document it.

One thing ISO9001 wasn't too great at was meshing with more complex IT systems, especially around security.   You could pass ISO9001 by saying high-level statements such as: "Everyone keeps their password secret", however the passwords could be held in plain text on an insecured server.  So along came ISO27001 to close that loophole.  ISO270001 is ISO9001 military-grade big brother.  It lays down the law on security processes and policy, and describes best-practice for maintaining secured information, and managing change control.  

 Effectively ISO9001 says "This is how we do our business, these are our procedures", and ISO27001 says ".. and this is how we make it secure, and keep it secure."..   But, even putting ISO9001 and ISO27001 together, there's still nothing filling in the details around how the business actually achieves the procedures set out, or what the structure of the business is.    So, back-filling this with:

• A network diagram and documentation
• Software documentation
• An org chart
• supply chain and logistics documentation

..and so on, one may approach a wholistic understanding of a business.    

However, every so often a new "approach" or "standard" for describing and documenting a business aspect is released, requiring a new raft of documentation, new accreditations, and probably more expense.  There are so many, the whole language of defining What, How and Who businesses do their thing has become complex and confusing. To counter this, a new ISO standard (ISO42010) has been created to standardise the definitions somewhat.  Not everyone agrees with every part of ISO42010, and you'll find many AFs take a few liberties with some of the definitions, but in general, 42010 is a good starting point.

 So, the tools may be out there to understand what you do, and (with a lot of work) how you do it, but how do you keep all this documentation managed?  Each of the above has a 'standard', which must be bought, trained-in, understood, and managed into the business.  Once complete, each system commends its own change control, owners, review boards, and so on.   Worse, how do plan on changing your core business?  Managing and changing the change-control can be as complex as changing the business it's there to protect!  The temptation is to 'wing it', and rely on everyone 'doing best endeavours' to cover all the aspects of the change control.

 However, businesses which attempt to grow or change too quickly without a defined plan  (the 'wing it' approach) will inevitably run into difficulty.  There are simply too many things which can go wrong. It just takes one member of staff to be on holiday or sick leave, to miss a meeting, and....  

• One can hire a team too early, and leave them with no work for months while a team they dependent on are still onboarding.
• New teams can be brought onboard whose capabilities overlap existing teams, creating duplication and wasting money.
• IT infrastructure may not be sized appropriately, causing outages, data loss, or wasting money on unnecessary intermediate systems.
• No defined "end goal" and lead to business uncertainty, shareholder disenfranchisement, and protracted changes impacting effectiveness.
• The business may simply be unable to support the new structure: It may be too expensive to be funded by revenue, the management team may be unable to cope with the ballooning staff numbers, and so on..
• If the business has to plough a lot of resource into the switch-over, can the business still support the current processes while the process is occurring?  If not, is there a plan for how the business will continue to operate until the new revenue sources comes on-stream?
• If the new architecture involves a lot of redundancies, do you have the financial aspect of the process covered?  Is the knowledge handover being managed effectively?  What will fall by the wayside?  Has a business function been identified to pick the important things up?

It's crucial therefore, that before one launches into a new change project, that three things are known:

1. What is the current business state
2. What is the desired business state.  Has it been validated?
3. What's the plan for getting from 1. to 2. 

Let's take an example:  Let's suppose you run a large logistics operation, shipping materials to and from destinations.   Let's assume that you want to start storing materials and charging rental.  Sounds simple, right?    So, how do you plan this business change?  Who do you include in the process?   There'll need to be:

• Infrastructure experts to plan the new warehouse, transport, cooling, heating, shelving etc.
• Logistics and Risk experts to plan on how you move the stock, store it, catalogue it.
• Support staff to be trained on the new procedures
• Lawyers to sort out insurance on your warehouses full of expensive stuff.
• Sales and Marketing to advertise the new capability.
• Short-haul drivers to distribute from the warehouse...
• IT and electrical infrastructure guys to put communications and facilities into the right places.
• Software support for the new inventory tracking systems

... the list goes on.   And now you have to review all your documentation to bring it in line with the new business change.  Should one choose off-the-shelf solutions, or tailor-make one?..

To try and address all this mess, the concept of an "Architecture Framework" was created.    There are a few to choose from, but I'll just describe a little about TOGAF for now.  TOGAF's got a good pedigree, coming from the US military, and adapted to the commercial sector. It attempts to bring all these different responsibilities and items into a single framework.  It allows an "Enterprise Architect" to build a "Baseline Architecture Description" of your business, from which a flexible but powerful process can iteratively migrate the current architecture to a new one, transitioning through a series of stable states.

TOGAF breaks your organisation into four components:

• Business Architecture (maps loosely to ISO9001)
• Data Architecture (databases etc).
• Application Architecture (which coupled with Data architecture map loosely to ISO27001)
• Technology Architecture (the actual IT infrastructure)

Once these four architectures are built, they're baselined and stored in a repository.  They can be used as templates for future changes.

TOGAF doesn't stop there, however.  It provides a process, the Architecture Development Method(ADM) which provides a set of rigorous steps, involving all levels of the business to ensure that the business change is effective in a controlled, inclusive manner.  

In short:  The ADM starts with a loose "desire for change", and then provides a set of steps to include the business, data managers, IT infrastructure guys, logistics, supply chain and other managers to gradually fill in the detail of the "delta" to the baselined Architecture Definition.  The result is a project plan for making that gradual transition, with checks and balances to ensure that the resulting architecture is that which is desired.

TOGAF is well suited to businesses with heterogenous functions, who have trouble exerting fine-grained control of their individual silos.  Such organisations can feel like "herding cats", due to warring department heads, competing budgets and unclear group goals.    

TOGAF isn't monolithic, however: most AF's arent, in fact.   It allows other best-practices to be imported into its "libraries", to enhance your toolset.  One starts from a "general definition" and use domain-specific tools and processes to produce a "specific definition" for your own business. These, then are held in the repository as "tools" for re-use elsewhere: Setting up a new BU, why not import the architecture from another BU, and adapt it?   The process is the same as modifying an existing BU!

So, if you're planning on taking your organisation forward, consider investing in an Enterprise Architect to map out your current Architecture Landscape, and kick-start the change management.   Although it sounds like "Big Enterprise" stuff, every business can benefit from the processes that AF's like TOGAF offer.  Above all, it recommends being inclusive:  The key message is: Don't rely on a single individual or small team to perform your business change planning in isolation: There will be too many things missed.     Start from a solid requirement stated by the senior management and gradually build towards a solid migration plan, with all stakeholders consulted, including customers and suppliers, if they feature as part of your key architecture!

AF's enable a single point of documentation and control. Importantly, once an unruly business structure is understood, it can be used as a basis for achieving the other ISO accreditations, due to the rigorousness of the architecture definition.   Effectively, an enterprise can start with a solid base, and  achieve accreditation on that, rather than running multiple documentation exercises which may end up not benefiting the business, except to have a shiny plaque on the wall by the front door, and a logo on the website.

You can find out more about Enterprise Architectures, and more specifically TOGAF on The Open Group's website here.