The following document is excerpted from a paper explaining the architectural approach to a non-technical executive audience.

                For many years computing technology in the workplace was seen as the preserve of the peddlers   of arcane knowledge, removed and separate from the world of “business” that everyone else inhabited. This was a separation  that was sometimes actively reinforced on both sides of ‘the business’/IT divide. ‘The business’ blamed IT when things went wrong and IT blamed ‘the users’ for not knowing what they were doing.

But in recent years substantial effort has been made to  not only bridge that separation but to erode it altogether. There is a simple reason for this: IT and ‘the business’ are one and the same. Everyday work entails massively complex technology, whether it be a PC with standard desktop software, a smartphone constantly chattering on the internet or a piece of kit like an MRI.  Technology is just a collection of tools enabling an organisation to undertake a set of activities.

Generations have grown up and entered the workforce who are as familiar with the basics of the technology as a previous generation was with pen and paper.  They understand the language of mouse and icons, they instinctively navigate websites and applications, and most crucially of all, they understand that change is constant and inevitable.

This change in the culture of users over the previous decade is easily overlooked, as we have become accepting of and inured to this rapid change. Equally overlooked is another great change: technology itself. Whilst there has been no fundamental revolution such as the personal computer or the internet, culture changing revolutions of the previous decades, there has nonetheless been a subtler expansions of possibilities enabled by technology. In the previous decade, advances in computing power, mobile device proliferation and internet usage and speeds have massively changed the ways that people interact with technology.  Even those who work in Information Technology often don’t recognise the scale of the change which has happened. As it has happened, people’s  expectations of technology have changed.  Instant access to information and services is the de facto standard, particularly for the generations that form the bulk of trainees.

These changes in technology and its symbiotic relationship with the culture have posed challenges for all organisations. Broadly put, these challenges can be described two ways:

•             External demands – the challenge to meet the service demands of customers outside the organisation

•             Internal demands – the challenge to adapt ways of working and grasp new opportunities

Many, if not most, organisations have had substantial problems embracing these changes. Firstly, because the sheer scale of the change is sometimes hard to grasp. Secondly, because a shortage of financing has restricted investment needed to utilise the new technology. As a result, the tendency has often been to take an “if it’s not broke, don’t fix it” approach.

This approach though misses a fundamental aspect of technologically driven change. No farmer would propose using a horse drawn plough in place of a tractor as both work, so why fix it, because the productivity advantages are obvious. No consumer keeps watching black and white television simply because their set still works. Technology enables change and through the act of enabling it sometimes makes change unavoidable.

The Architectural Approach:  Benefits of seeing the Big Picture

                There is in fact still considerable debate and confusion even within IT what an architectural approach entails. As if to prove that they are equally resistant to change as anyone else, many ‘old school’ IT people view architects as simply senior developers with bad attitudes. Most Enterprise Architects on the other hand would say that their work has only a limited IT component and much of the practice is business facing. It involves looking at the big picture, at the organisation as a set of interconnected people, processes and systems. A and this interconnectedness means that there are no stand-alone solutions. 

Designing for customers not IT

So what does the architectural approach practically involve? An analogy can be drawn with the role of a traditional architect. The customer says ‘Build me a house with 3 bedrooms and a kitchen’.  An architect’s role then is to understand what the customer wants in more detail – how big should the bedrooms be? Who are they intended for? Should they be en suite? Should the kitchen be separate from a dining room or will it also be a dining space? There are many requirements to detail before the architect can agree a design with the customer. The design will then be handed over to the builders and the architect remains engaged to represent the needs of the customer.

                This then is the crux of the architectural approach – to disappear that divide between customer and builder, between ‘the business’ and IT.

Just as a building architect operates within a framework of technical knowledge – the physical properties of different materials, the legal compliance of safety regulations, etc… - so too does the enterprise architect.  Understanding what is technically feasible and explaining the opportunities offered by technology, the architect should empower the customer to be engaged with the process of design and development.

Comparing Old and New Models

When delivering a programme across an enterprise organisation, or a group of organisations, there will be many different parties wanting many different things. Understanding how the requirements of different customers can be met within one overarching architecture is central to the approach, because it is here that the concept of reuse comes into its own.  Different parts of the business will always have different requirements, but because they all fit within the wider set of organisational activities, there is inevitably crossover between requirements for different projects. By breaking the different projects into their constituent parts, architecture creates building blocks. These are reusable components with which to build anew.

This is where the great advantage of the architectural approach over previous methods becomes clear. Traditionally, the IT model was: one solution for one requirement. So the picture evolved something like this:

•             One department has one set of requirements. These are met with a stand-alone solution.

•             A second department has another set of requirements .  Another stand-alone solution is provided.

•             A third department needs data from the first two departments to use for a new set of requirements. Another stand-alone solution is provided and data is extracted from the first two systems manually.

Every time a department came along with a new set of requirements came along, a new system was built, with separate support and separate user groups.  Each time data needed to be moved from one system to the other, or data was needed to be aggregated from two different systems, manual processes and worksheets proliferated.

Every time a change was needed, the suppliers of the different systems were engaged to develop the change, and this became the business model for many software suppliers. They customise each implemented instance of their system in each separate location and tied their customers into on-going development and maintenance contracts, constantly tweaking a multitude of tailored systems. Because of their monopoly and the dependency of their customers, software companies can then charge whatever rates they wish. Day rates of £1500 are not unusual. This highly profitable business model for IT vendors also entails a high Total Cost of Ownership (TCO) for their customers (see below).

Crucially, this approach is also very resource intensive. Operators and IT support need to be separately trained for each individual system, each with its own individual quirks. Manual processes require more people to build and maintain worksheets. And as the cost of upgrading or replacing a business critical system escalates, so the stand-alone solution becomes more outdated and needs more and more effort to maintain.

In contrast, the architectural approach emphasises standardisation and reusability and would look something like this:

•             One department has one set of requirements. The architect looks at how these requirements fit within the overall business. The provided solution is designed with standardised functionality and ready to integrate with other systems.

•             A second department has another set of departments.  The first solution can be extended to meet the new requirements.

•             A third department needs data from the first two departments to use for a new set of requirements. A new set of functionalities  is provided. Data management is put in place to ensure there is a ‘single source of the truth’.

Here, the principles are to extend and reuse where possible.  Meeting requirements is a question of providing a service, and these services can be adapted and changed as new drivers alter the situation. Hence, this is referred to as Service Oriented Architecture (SOA). Data is separated out but is readily exchanged between systems, always ensuring that there is a master data source which can be maintained as the single source of truth.

Changes then are made in one place. Standardisation means that developments are done in ways which are readily understood by developers and business users alike. The Shared Information Services strategy has been to use common technologies, which ensures that development is done with widely available skillsets; contractors can be readily found and internal resources can be trained. And crucially, the dependency on (often small) costly suppliers is removed.

So the architectural approach can demand somewhat more time and effort upfront, but the savings are made by seeing the big picture. Because the technology is standard and the applications all work in the same way, people can use and support the system across different areas. Without the manual effort to exchange data between different systems, the user base is lower.

The upshot is less cost to develop, deliver, maintain and use the systems. A lower Total Cost of Ownership dramatically offsets any initial equivalence in Capital Expenditure.