Category Archives: Enterprise Architecture

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.

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