Enterprise-architecture – which way forward?

Which way forward for enterprise-architecture?

It’s common to think of enterprise-architecture (EA) as a discipline that’s mainly about getting the best use of the organisation’s IT. Yet whilst, yes, most job-descriptions for EA these days will still revolve around some aspect of IT, that’s not all that there is to it – and it’s not where it most needs to be, either.

The scope of enterprise-architecture

To illustrate the point, let’s think for a moment about where modern EA started, as a means to rein in the rising costs and complexities of IT infrastructure.

But to understand what we need from the IT infrastructure, we need to understand the applications that run on that infrastructure.

And to understand those applications, we need to understand the data that they manipulate and maintain.

Then to understand the data, we need to understand its business use.

Which means that we need to understand the business purpose behind that use – the strategies and so on.

And to understand that business-purpose, we need to understand the business-ecosystem in which the business operates.

And so on, and so on…. everything depends on everything else.

Because if we don’t have at least some understanding of all of that, we’ll likely end up with the wrong architecture for the IT infrastructure – and perhaps just about everything else in-between, too.

Which is why EA frameworks such as TOGAF and FEAF and DoDAF and the rest typically insist that we look at not just the IT infrastructure, but everything else on which it depends, at the very least up to the ‘business-architecture’ level.

And then they come back to IT again – with ‘business-architecture’ in essence regarded as ‘anything not-IT that might affect IT’.

Which would be fine if businesses consisted solely of information and information-technology.

Which, in most cases, they don’t.

And that’s where – and why – things are starting to change in EA. Increasingly, we need the EA to be a literal ‘architecture of the enterprise’ – not solely the architecture of the enterprise-IT.

A practical example

Let’s take a real, practical, everyday example. Yesterday I had to go visit my bank to sort out a minor mess on one of my credit-cards: a straightforward problem, but one that I couldn’t sort out through their online-system.

(Note #1: Straight away this is larger than IT alone – this is something that’ll take human judgement to resolve, and we can’t build that into an IT-application itself.)

I go into the bank, discuss the problem with the front-line receptionist, who hands me over to a sub-manager in their credit-cards section.

(Note #2: This indicates an ‘architecture of responsibility’ – again broader than just IT-infrastructure, or even IT. We’ll see more of this in a moment.)

We go into the sub-manager’s office. Part of the problem is that I have seven different accounts with the bank, and two of these accounts have debit-cards that also act as credit-cards. But the real problem is some of the accounts are personal, and some are for business – and their online-system couldn’t cope with anything that bridges across that arbitrary divide.

(Note #3: An organisation’s systems and their architectures will often seem to make sense in terms of that organisation’s own business-structure, but not necessarily to anyone else who has to use the system – especially any ‘outsider’ such as a customer.)

She logs into her terminal, and pulls up my personal-account details on her screen. She makes a set of handwritten notes on her note-pad, then logs out of that application, logs into a separate application in order to review my business-account details, and makes some further handwritten notes from that display. She explains that the bank doesn’t have any way to show a single view of all my accounts, because ‘Personal’ and ‘Business’ are two separate divisions.

(Note #4: When an organisation’s systems are fragmented by arbitrary boundaries, users have to resort to error-prone kludges such as handwritten notes in order to bridge the gaps.)

She calls the bank’s internal credit-card support line.

(Note #5: To make sense of this, we need to see the customer-support system as a whole here, including the ‘human-in-the-loop’ parts of that system – again, there’s more to it than just the IT and its interfaces.)

The representative asks for a security-code to verify that she really is calling from the bank-branch. She opens another application to obtain a one-time code-number.

(Note #6: Again, the IT-applications here are all partitioned by business-department – there’s no continuity, and no easy way to move between sub-tasks that bridge across those different departments.)

They talk briefly, then discover that she needs to call a different support-line in a another department. She ends that call, looks up another application to find the correct phone-number. She then manually dials that number, and starts the conversation all over again, with all of the same customer-details, with another support-representative. Before they get far into the conversation, he asks her for the same type of security-code. She closes the current application on her screen, open up the security application again, and obtains the new one-time code-number, which she reads back to the representative. The conversation continues.

(Note #7: The fragmentation of the overall process by an organisation-centric architecture is all too evident here – switching manually between different applications at almost every step within what is actually the same overall task. Several obvious options for automation are also missed, such as auto-dial on the phone.)

They talk back and forth, until they finally identify what the problem is, and that it has been moved to yet another department, who are the only ones who are allowed to make the necessary decisions. They end that call, and the sub-manager goes through the same rigmarole all over again, to talk with this other department.

(Note #8: The human and financial costs to the bank of this fragmented process would be obvious to any ‘outsider’, and probably to most employees too, and yet they’re largely invisible to the bank itself because the costs are incurred between rather than within departments.)

Unlike the others, the representative at the other end of this call does have a more consistent whole-of-customer view, and is indeed able to sort out the problem. What he doesn’t have is my personal authority to do it. So at this point the phone is handed over to me, and we have to go through all of the charade of working through a predefined script to verify that I am who I claim to be, even though the branch sub-manager has gone through that at least twice already with the other representatives, and knows me personally anyway.

(Note #9: Remote identification, verification and management of identity is a real challenge, but would be better all round if the system had been able to maintain at least some kind of identity-state across the complete set of interactions.)

Eventually, and after more switching between applications on both sides, to set up new standing-orders and suchlike, we finally get completion. Everyone happy all round. Except that it’s taken almost an hour to do it, involving at least five different members of staff at the bank, and countless different disconnected applications.

Surely it could have been done a better way than that?

Finding a better way

And yes, it’s the job of an enterprise-architect to find a better way to do it, and work with others in the organisation – solution-architects, system-designers, service-designers, project-managers and more – to get that better way designed and built and put into practice.

Yet as you’ll see from those notes above, doing so would require a far broader scope than just IT. It needs an holistic view of the activities as a whole; it needs to understand not just the IT-based processes, but the human processes, and human responsibilities too; it needs to identify and clean up the kludges that people have to do to get round the limitations of the system. There’s a lot of work to do just in that alone.

But perhaps even more, the architecture needs to support not merely one organisation-centric view, but any required view. Employees will need a ‘single view of customer’, for example, that bridges cleanly across any and all departments as required. Perhaps even more, the customer needs a ‘single view of organisation’, an ‘outside-in’ view that’s consistent regardless of whether the other side of the line is an IT-system, an automated phone-line or a real person.

Yes, it’d probably be hard to design and build that kind of whole-of-context system, and the politics of it all could well be harder still. But it’d be an architecture that actually works, and would be a lot more resilient and robust than the usual silo-oriented structures – and a lot lower cost all round to operate, too. In other words, a challenge that’s well worth the effort.

And taking up that kind of challenge is the way forward now for enterprise-architecture – expanding the scope outward to a true ‘architecture of the enterprise’, and acknowledging that within that architecture everything really does depend on everything else, working together, on purpose.

An interesting challenge indeed: interesting times ahead for enterprise-architecture!

—

(Note: This blog-post was originally written for the Unicom weblog, as part of the lead-up to their September 2013 conference ‘Enterprise Architecture and its Application‘, and was initially published on their weblog on 16 September 2013.)