Carefully exceeding the mandate

It strikes me that many enterprise architecture groups are stuck in IT departments desperate to break free from the shackles of solution architecture and talk to the business yet hampered by a constrained job description, limited by their own leaders' perceptions and invisible to leaders beyond IT walls. So often I hear people talk about their practice of enterprise architecture as though the bonds have been broken. On deeper questioning, however, it becomes clear the mandate under which they are operating remains unchanged. I cannot help feeling that these groups are simply delusional. I wonder too how they continue to deliver on their restrictive mandate as they must be spending a large amount of time doing things for which they have none.


There is no easy answer on to how to draw an enterprise architecture group out of the shadow of IT. I suspect the answer is different for every group and every organisation - as is the nature of cultural change. My suggestion is to ensure you pay attention to deliver the things you are tasked with and be intentional (I mean really develop a plan for it) about nudging those around towards a different view of the your true value. I don't believe this is an enormously difficult task if approached in the right way and with the right set of skills. I believe this because I believe in the value of architecture at the enterprise level.

Who is accountable for application sprawl?

In my last post I mentioned application sprawl. In many organisation, like self replicating nano-bots, the list of applications that enables the business to function increases uncontrollably. The IT organisation tries to bring some order to this chaos with limited success.

We try demand management techniques, which may be designed to help people to stop and think but are largely seen as barriers to change,dampeners on the springs of agility. We enforce standards, erect governing bodies and create IS Strategies (aligned with business strategies, of course). Despite all this effort there are still the exceptions justified by "my case is special"; and let's not open the can of worms that is self-built solutions - those excel spreadsheets, access databases and (heaven forbid) the unauthorised use of free services on the web.

This is application sprawl, and it exists to some degree or another in every organisation large enough to have an IT department (and probably many that don't as well).

The need for an application inventory

Application Sprawl is an ever present reality for enterprise architects. Is it the role of EA or the IT organisation to constrain this sprawl? Does such constraint hamper business innovation? Or is the limitation in agility a worthwhile price considered against the long term consequences of an unmanaged, unconstrained application portfolio? Is application rationalisation a reality or is the way we look at platform services creating an illusion that is simply masking sprawl of a different sort?

It is logical that platforms of shared capability or components that are reused will be cheaper to operate and maintain than duplicated capabilities – especially those built on different technologies. Killing two birds with one stone increases return on investment receives little argument. This is as true of technology as any other aspect of the enterprise; or life - the TV in my kitchen doubles as a computer monitor. However, shared platforms simply create another container for more applications. Is a dashboard less of a business application than a web application simply because it is hosted on a BI platform and not an application server? To be absurd you might reduce the whole data centre to one application.

Consumerisation trundles on

A friend just posted a link to "Client4Cloud: Desktop Transformation to Universal Clients" that got me thinking again about the whole consumerisation thing. Quick context: I haven't read the book, although I've just skimmed the sample, so I'm not saying anything about the content or message of the book - simply that it's appearance on my facebook stream of news has prompted this post.

Here's one scenario that has always seemed to me to be a barrier to consumerisation; at least for now. Let's assume we deliver a virtual desktop to our workforce and allow them to bring in their own device (laptop, ipad, whatever). One of the employees comes in today and says his laptop is broken. He's taken it in for repair and it will be a week, so he's a bit stuck and can't do his job. Whose responsibility is it now that he is unproductive?

Of course, there are loads of ways around this. We could have a stock of loaner laptops to dish out in times such as this. However, it just all starts to look rather untidy. We're still managing kit, which consumerisation was supposed to get away from. I'm sure it works better on a small scale with a workforce in the 10's; but scale this up to thousands and I just don't see it.

The flip side is give everyone a laptop that is not locked down, controlled and inflexible. Use virtualisation to deliver the standard set of tools and isolate it from the user-play-area in which enables the employee to make a productive tool for her to do her work.

The world has moved a long way since the early days of machine and then application virtualisation. I haven't really kept a close watch on this area for a few years, but I'm about to do another round. It will be interesting to see what's changed while my eyes have been diverted on other things.

Managing Requirements

I just posted these thoughts on managing requirements on G+: https://plus.google.com/u/0/103322217256114006757/posts/5ZBmgU1umq7

Sailesh wrote an interesting post on requirements here: https://plus.google.com/u/0/115629371379295233882/posts/7sTEwaUA6Cj.

I agree with him that management of requirements is so important, but a challenging thing to do and not helped by the tools we have at our disposal. Nevertheless, manage them we must and I organise the requirements I come across into Business strategy, Functional requirements and Deficiencies.

Strategy/Vision is perhaps not strictly speaking a set of requirements. However, as change can arise directly from strategic initiatives I capture them as requirements, although I might equally create functional requirements derived from strategy elements.

Functional requirements are things that we would like to, but are currently unable to do. This might be launching a new product or reducing travel through the use of video conferencing. Deficiencies capture requirements that address things that aren't quite right in the way the business operates or in the applications, data or systems we use.

I intend (but don't always succeed because the model isn't complete) to trace all functional requirements and deficiencies back to a source: either business drivers (captured as strategy requirements) or business process or technology.

I am using Sparx EA to model requirements along with the conceptual model I have been building of the business process and application landscape. As Sailesh points out, the tools available aren't great, but manage requirements we must... so a man's gotta do... I'd love to know how others have tackled this challenge.

Managing the Mix

I presented a 5 year plan to the board last week. One aspect of the presentation that seemed to resonate really well was an adaptation from the Pragmatic EA Framework's Enterprise Debt. However, I re-badged the terms Remedial, Tactical and Strategic as Deficient, Temporary and Permanent.

I found the term Remedial a bit ambiguous - is it a remedy or in need of a remedy? The intent is 'in need of', but to avoid confusion I chose deficient. We live with deficiency in all aspects of our lives - I have a headache, but I soldier on; the handle on the toilet is wonky, but it still flushes OK so I leave it be; we are a headcount down in our department; our systems don't integrate. Some deficiencies obviously more severe than others.

To address deficiencies we find a remedy, which can either be temporary or permanent. I prefer this to tactical and strategic, largely because tactical has become associated with quick, dirty and cheap, and strategic with expensive and (potentially) over engineered - at least they have in my mind.

So the distinction I draw is whether the remedy will no longer be used, replace by a different solution, at a planned point in time, or one with no foreseeable event that will trigger replacement, even if a desirable replacement exists. Many solutions are built with every intention to replace them, but that replacement never comes - hence the emphasis on a known point in time or triggering event.

Putting this into the presentation gave the roadmap a sense of pragmatic commercial awareness, which can often be lacking when the focus is on technology. It acknowledges that in all areas, technology included, we manage the mix of deficiencies and remedial measures (temporary and permanent). Each section of the roadmap referred to the changes in terms of deficiencies and temporary or permanent remedies.

I didn't get into the ratio measurement proposed in PEAF, partly because the application inventory doesn't use this language yet and partly to take small steps in introducing this new language/model; let it gain traction and then develop it.

I encourage you to read PEAF. How have you used this concept?

UPDATE: So I abused the PEAF terms, doing something a bit different. Made sense in the context of painting current state. I'll have to read over the PEAF material again.

Some good reminders

Andrew McAfee has posted some interesting articles on the adoption of E2.0 applications. His most recent post, Is Management the Problem?, seems, inadvertently, to be a pretty good summary of these posts.

Is this just because he's been right all along ;-)?

I'm convinced that our success with news feeds (RSS et al) is due, in no small part, to getting senior management to experience it and use it. I can see the same pattern emerging (oops, no pun intended) with some E2.0 apps, although I'm not prepared to say which here.