IRM UK EA/BPM conference - Achieving business outcomes with enterprise architecture a major theme in the event

Last week QPR sponsored IRM UK EA/BPM conference that took place on 16-18 of June 2014 in London. QPR’s UK reseller Performance Analytics joined QPR in the event to promote QPR’s comprehensive and innovative enterprise architecture (EA) offering. The event brought together both EA and BPM experts from several countries and provided a venue for excellent discussions and presentations.

QPR team in full action at the stand

A clear theme in the EA area was that EA should focus on delivering concrete business outcomes and provide value to the key stakeholders of an organization. This theme was strongly emphasized in the event key note speech “Who Cares?: Getting a Grip on your Stakeholders’ Needs and Expectations” presented by Roger Burlton from BPTrends Associates. Burlton highlighted that the starting point for EA and BPM efforts should be to look at the needs of the main stakeholders’ of the organization – such as customers, owners etc. – and focus the efforts on delivering value to them. Burlton also emphasized the importance of performance measurement as part of EA work to demonstrate the results to the management and highlight the results with visually appealing dashboards and reports. Other dominating EA topics in the event were the significant role of EA in business transformation and strategy execution, as well as business architecture, which had its own track in the conference agenda.

As usual, the discussions at the expo floor proved to be very interesting and QPR’s comprehensive and innovative EA offering created a lot of interest.  Notably, the QPR business driven approach to EA received a lot of interest among EA and BPM practitioners. This was a really positive sign, as typically the ideas of the methodology gurus presented in conferences are ahead of the actual, real-life practices in organizations. But this year’s IRM UK event indicates that the gap between business outcome driven EA and traditional IT oriented EA is narrowing, as practitioners also seem to be keen to adopt this new approach. Or is there still a clear gap? Thoughts?  

Tero Aspinen

Director, Partner Management

fi.linkedin.com/pub/tero-aspinen/2a/592/344/

How to get started with Enterprise Architecture? Looking at enterprise from IT perspective. Part 3/4

An optimal way to start creating enterprise architecture (EA) work is first to look at it from the business viewpoint. But what if you don’t have time or the possibility to do so but you are given a straightforward task, say, to either harmonize your IT application landscape and reduce some IT costs or change technology behind the applications, or even both? In this kind of case, chances are you don’t have the luxury of time. In spite of this, if you are going to cut the power from some ICT systems, servers or services, it would be nice to know from whom you are cutting down those services and how does it affect business operations and processes continuity.

If the only thing you know of your enterprise architecture is a list of ICT systems and their names, and you are lacking the knowledge of business process architecture, I’d say now is a good time to start your EA work by not only making a system acronym list of those ICT system names, but also understand functionality of those ICT systems and what kind of information they are dealing with. In an ideal situation you would also know who the users are of those applications, so you could at least ask them about the functionalities and data usage – the so called use cases.

If you are in a hurry to do something with your IT application’s architecture, this kind of quick use case walkthrough of applications, information assets and related functionalities would be your first action point when starting with EA. Later on, when the dust has settled and you have managed to solve your IT application and/or technology issues at least for a while, I’d suggest that you continue and expand your EA work by connecting those application use cases to business processes. If you don’t have business processes defined by the business, use instead some industry standard process framework close to your organization’s business area. They might provide a good starting point for process architecture development anyhow.

In a perfect world, your enterprise architecture work would have started from organization’s business strategy, operations and business information topics, and you would also most probably have a good understanding of your business processes which show how your organization is running its business. If this would be your starting point, connecting IT to business architecture would be a piece of cake. If that business architecture layer is missing, you can still start EA work from the application and technology side using information usage and use cases as linking glue.

Ari Anturaniemi
Chief Consultant, Enterprise Architecture

fi.linkedin.com/pub/ari-anturaniemi/3/572/a51/

How to get started with Enterprise Architecture? The topic of having common language and information. Part 2/4

One of the key things I have found most important when starting discussions around enterprise architecture (EA) matters is to communicate and understand people by using their own everyday language. Even if speaking the same language (e.g. English), it doesn’t necessarily mean people understand things the same way. One word written and spelled the same way can have different contextual meanings for different persons (for example, term ‘product’ might mean to a retailer the combination of the sales package and the stuff inside the box but for the manufacturer it might mean that the sales package is just the material part and the thing inside the package is the actual product). Therefore, you need to be able to define and explain a meaning of a word or a phrase using other words than the word or phrase itself.

Terminology can change depending participants of discussions. When asking ‘what do you mean with that thing’ or ‘what is your definition for that term’, I have found that there are no stupid questions when driving for common understanding between people. Therefore, when starting any kind of enterprise architecture related discussions or work, start it by creating a glossary of concepts and terms first, and also try to understand how different terms relate to each other.

After making that vital glossary of key business terms (data about terms and their definitions), create also a conceptual information model showing how terms relate to each other. Understanding the context how different kinds of terms and words are used in business and how they relate to each other is also the basis for the information architecture creation which is very important part of your enterprise architecture deliverables.

Since EA’s purpose is to create a systematic big picture of all matters related to an organization, using the language of the organization makes your enterprise architecture more understandable for everyone. When discussing with Enterprise Architects about enterprise architecture, there is a good chance we are already using a common vocabulary of EA methodologies, especially if architects are familiar with e.g. TOGAF or some other EA frameworks. But do not expect any other person than another Enterprise Architect to understand that EA jargon. Therefore, it is crucial to speak the language of the business.

So, if you are an Enterprise Architect, as a first thing you need to create a glossary of the business, learn the terms and adopt them by creating a conceptual information model of the key concepts and their relationships. That is also one of the most valuable enterprise architecture deliverables you’ll make and keep up to date. If you are a business stakeholder, help those persons trying to construct a business glossary since you’ll find it a very useful tool later on in your own work when discussing with people about your business.

Ari Anturaniemi

Chief Consultant, Enterprise Architecture

fi.linkedin.com/pub/ari-anturaniemi/3/572/a51/