Bad Blogger

Posted on by

One of the cardinal rules of blogging is to write blog posts regularly. What haven’t I done for a year? Written a post on this blog. I’m not about to write a year’s worth of detailed content in one go, and even if I managed to do it I doubt anyone would have the time to read it, but instead I will try to give a bullet point update on some of the EA activity over the past year. I’ll even embolden the main part of each point in case you only have time to skim read this…

  • A light-weight approach to TOGAF has been adopted, which we’re calling TOGAF-lite. We engaged a consultant to help us with this work, because picking out the most relevant or useful parts of TOGAF for our situation is very difficult with no previous experience.
  • ArchiMate has been adopted as the EA modelling language, and BPMN as the detailed business process modelling language. As much EA documentation as possible is done in ArchiMate rather than in textual documents, and this is reflected in the TOGAF-lite approach.
  • A single tool has been selected for ArchiMate and BPMN modelling and storage (BiZZdesign Architect).
  • Core business processes have been documented in ArchiMate and BPMN.
  • An Enterprise Service Bus (ESB) and Master Data Management (MDM) project is underway to significantly improve the way information is moved, shared and managed between corporate applications, and how important data itself is managed.
  • Architectural standards for new ICT solutions have been set, in what has been called the ‘Solution Architectural Requirements’ document. This will primarily be used during procurement exercises for new systems and will help us to ensure that new systems fit appropriately into our overall IT architecture.
  • An Architecture Advisory Group (AAG) has been formed. The AAG is composed of various academic, student and professional services representatives at the University together with a couple of external advisers too. The aims of the group are to provide advice on EA initiatives and strategy, encourage adoption of EA across the University, and provide feedback for improving the effective implementation of EA.
  • A Systems Architect has been recruited who is concentrating primarily on ESB and data architecture.
  • The architecture repository, or master model, in BiZZdesign Architect is gradually becoming populated with more and more information. Much of this is being done as part of projects to introduce, extend or replace systems.
  • EA activities have been included in the standard ICT project structure to ensure they are included in all appropriate projects.
  • An Architect’s Handbook has been drafted, and now includes how to approach EA in projects, how to approach EA as a project in its own right, how to manage the repository and how to model in a consistent style to allow for later analysis.
  • High level architecture vision discussions have been taking place including the approach to cloud hosting (IaaS, PaaS, SaaS), the desire to reduce number of suppliers and enhance business continuity and data security, foundation projects (ESB & MDM, CRM, SharePoint) and the impact of hosting options on them, alignment of particular areas such as dependencies of Digital Education Strategy on VDI (cloud desktop), and CRM with email, file storage and office suite.
  • The approach to ESB and MDM has been established, guiding principles set and a high level blueprint created.
  • A BizTalk consultant has been engaged on a short-term contract to assist with implementing BizTalk and transferring knowledge to ICT staff.
  • ArchiMate and BPMN overview training has been provided to ICT Project Management and EA staff.
  • An ‘EA Ambassador Pack’ is being produced to help those who will be EA champions to spread the message about EA to others in the University.
  • ICT is engaging with the UCISA EA Community of Practice group to exchange ideas and information with other Universities, including speaking at some events.
  • An investigation and trial is in progress to establish whether use can be made of certain Microsoft technologies for authenticating people who are not members of the University against certain IT resources. For example in future this could be used for allowing applicants or alumni to log in to certain services.

 

Archimate

Posted on by

Archimate is a modelling language for Enterprise Architecture. We are adopting as the EA modelling language at the University, and it has been adopted by The Open Group which also maintains the TOGAF standard.  As of version 2.0 the main language corresponds with phases B, C, D and E of the TOGAF ADM, and it has extensions that closely relate to aspects addressed in the Preliminary phase and Phase A.

Archimate represents the enterprise architecture in Business, Application and Technology layers, and in each layer there are active structure elements (capable of displaying behaviour), behaviour elements (the unit of activity performed by one or more active structure elements) and passive structure elements (on which behaviour is performed). Elements ‘connect’ to each other through relations such as association, access, used by, aggregation and composition. Elements can be put into groups, mainly for ease of conceptualising a view.

My view, and that of many others, is that Archimate should be used for the high-level view of the enterprise and, taking business processes as an example, going one or two levels deep into processes. It would not normally be used for detailed business process modelling though, with that requirement better met by a notation such as BPMN.

The full specification is available from The Open Group, but I would also suggest reading Mastering Archimate by Gerben Wierda for a good guide on practical uses of Archimate.

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).