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.

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