Tag Archives: enterprise architecture

TOGAF

Posted on by

The University is adopting a ‘light touch’ TOGAF approach to Enterprise Architecture (EA). TOGAF, which stands for The Open Group Architecture Framework, is an EA methodology and framework. It is designed to support the four commonly accepted domains of EA:

  • Business architecture, which describes the University strategy, governance, organisation and processes.
  • Data architecture, which describes the structure of the University’s logical and physical data assets and data management resources.
  • Application architecture, which provides a blueprint for the individual application systems to be deployed, their interactions and their relationships to the core business processes of the University.
  • Technology architecture, which provides the logical software and hardware capabilities that are required to support the deployment of the business, data and application services. This includes IT infrastructure, middleware, networks, communications processing and standards.

One of the most important aspects of TOGAF, and almost certainly the most widely recognised part, is the Architecture Development Model (ADM).

TOGAF Architecture Development Method (ADM)

The ADM is a step-by-step approach to developing an enterprise architecture, and a cycle of the ADM is essentially an EA project.  The ADM consists of a number of phases that are iteratively repeated with frequent validation against the organisation’s current requirements.  TOGAF defines the steps within each ADM phase are defined in detail.

During the Preliminary phase, which takes place before an organisation can begin its first EA project using TOGAF, the “where, what, why, who, and how we do architecture” in the enterprise is defined. During the Architecture Vision phase the scope of the cycle or project is determined, stakeholders identified and a high-level architecture vision created – is is essentially the project start-up. It is important to carefully define the scope in terms of breadth, depth and time period based on what is to be achieved and what resources are available. Trying to tackle too much will generate a huge architecture project that could well be impossible to complete, whereas a too small or too specific scope could provide something that does not consider wider architecture implications sufficiently. Phases B to D share common steps to establish the baseline and target architectures, and then an initial roadmap is developed in Phase E before being finalised in Phase F where more detailed work packages are defined. Phase G concentrates on ensuring conformance of solutions with the target architecture and Phase H is a continual process of maintaining and monitoring the enterprise architecture and initiating new cycles.

TOGAF Structure

The structure of the TOGAF standard is divided into seven parts:

  • Part I: Introduction. A high-level introduction to the key concepts of EA and the TOGAF approach.
  • Part II: Architecture Development Method. The core of TOGAF, explained above.
  • Part III: ADM Guidelines and Techniques.  A collection of guidelines and techniques available for use in applying the ADM.
  • Part IV: Architecture Content Framework. A description of the TOGAF content framework, including a structured meta-model for architectural artefacts, the use of re-usable Architecture Building Blocks (ABBs) and an overview of typical architecture deliverables.
  • Part V: Enterprise Continuum and Tools. A discussion of appropriate taxonomies and tools to categorise and store the outputs of architecture activity within an enterprise.
  • Part VI: TOGAF Reference Models. Provides two architectural reference models: the TOGAF Technical Reference Model (TRM) and the Integrated Information Infrastructure Model (III-RM).
  • Part VIII: Architecture Capability Framework. A discussion of the organisation, processes, skills, roles and responsibilities required to establish and operate an architecture practice within an enterprise.

Other key aspects of TOGAF include the Architecture Repository and the Enterprise Continuum.  A lot of information is generated from doing EA, and the information needs to be effective managed in order for it to be useful and re-usable. The repository is where the information is stored and referenced.  It gets built up over time, and at the start might only contain reference models and material. The The Enterprise Continuum effectively provides contextual views of the Architecture Repository and a model for structuring and classifying those views.

The manual for all of the above is nearly 800 pages long, and you can imagine that used in its entirety TOGAF would be a very heavy weight framework. However, TOGAF is designed to be tailored and there are steps in the Preliminary phase to do just that. This tailoring aspect will be very important to the University’s start in using TOGAF effectively, and it is likely that it will need refinement over time as we all become more familiar with using the framework.

What is Enterprise Architecture?

Posted on by

That seems like a reasonable question to answer in the first post on an enterprise architecture (EA) blog. There are any number of definitions, but here are a few I have picked out:

“an architecture in which the system in question is the whole enterprise, especially the business processes, technologies, and information systems of the enterprise” (Microsoft, Tupper (2011, Data Architecture: From Zen to Reality) and Sessions (2008, Simple Architectures for Complex Enterprises))

“High level strategic technique designed to help senior managers achieve business and organisational change” (JISC)

“A means for describing business structures and processes that connect business structures.”

“a conceptual blueprint that defines the structure and operation of an organization.” (TechTarget)

“understanding all of the different elements that go to make up the enterprise and how those elements interrelate” (IFEAD)

“a coherent whole of principles, methods and models that are used in the design and realisation of an enterprise’s organisational structure, business processes, information systems and infrastructure.” (Lankhorst et al, 2005, Enterprise Architecture at Work)

A very popular one seems to be the first in the list. I think JISC’s (the second in the list) is also useful. For me though, the following are the most important elements when trying to define EA:

  • EA is a transitional process (state to state) and a product (documented representation)
  • EA translates an organisation’s strategic vision and objectives into organisational change. You need to know what the organisation wants in order to work out what the architecture needs to become.
  • EA is a strategic management technique – it is a documented, well tested, recognised way of doing things.
  • It is about people and organisation as much as systems and processes.
  • It is holistic.

Done properly, EA should address system complexity – often by simplifying systems architecture – and poor business alignment. It was recognised two decades ago and has been successful in the commercial sector for about 15 years. Although still relatively new in the education sector, it has growing momentum. EA should reveal the fundamental technology and process structures currently in place (as-is) and what needs to be put in place (to-be), and then get from the former to the latter through projects on what is often known as an EA roadmap.

JISC lists a number of ‘warning signs’ that indicate EA may benefit an institution, and I think it is fair to say that some of these are certainly the case here at Lincoln. For example, a few I think apply are:

  • Data exists in silos
  • Significant work is needed to take data from one system, manipulate it and enter it into another system
  • Lack of information integration means that staff and students have to visit multiple systems to get the information they need for daily work
  • Business process duplication means that the same activity is being completed by different systems across the institution
  • Different parts of an organisation give different answers to the same staff/student questions

John Zachman is said to explain EA by pointing at a wall and announcing that if you needed to change your building for some new purpose or challenge, and wanted to (for example) remove a wall, you’d have three options.

  • Knock down the wall and see what happens.
  • Employ engineers to spend significant time drilling holes in the wall trying to work out how it’s constructed and how it can be removed.
  • Dust off the plans for the building and do the necessary calculations.
In most circumstances we have to do either the first or second of these – obviously the aim is to be able to do the third, and EA will help us be able to get to that point.

JISC have identified a ‘Roadmap to Value’ as a simple way of estimating how ‘advanced’ an organisation is with EA.

I would say we are currently at the Explorer stage (researching and investigating EA, identifying potential change projects, developing a case) but swiftly moving into Adopter (planning, orienting, engaging with colleagues, designing a live project).