Like most people who got interested in enterprise architecture, I came to it from an IT background – developing and deploying enterprise-style applications into business. My frustration, no doubt shared by most people on the same trajectory, became most noticeable when we started using service-oriented architecture in a couple of the applications we had developed ourselves … and the recognition that this was a very useful deployment framework not matched by most applications at the time; I went very quickly from an application-centric view of technology functionality to a more abstract architectural one.
For me, moving from a technical abstraction to a business one was almost immediate – building agility into the business itself was increasingly important to survive and thrive; the service-based business was even more important than the service-based provision of technology.
So – the hunt for knowledge began. And I noticed the same things as many others about what was out there: large, “boil the ocean” methodologies and frameworks that appeared to be little more than a checklist (albeit a useful one), or a method for creating a framework … very little of practical, day-one applicability for most businesses. It seemed almost a prerequisite that you had to spend years and millions before you had a tool that you could actually apply to making architectural changes to your business – a very long road to achieving value from enterprise architecture. It’s no wonder that some attempts at it ran out of energy before they were finished.
Fortunately, over time (and no doubt some failed projects) a more pragmatic viewpoint has surfaced from experienced practitioners, and either some more lightweight (but not necessarily less rigorous; lighter in scope rather than depth) frameworks have surfaced, or experience has shown that it’s not realistic to expect to implement ALL the TOGAF elements before the business wants to see some results, and a lower-ceremony approach is starting to be seen. Without passing judgement on either, the titles of two I’ve come across give the sense at least that a phased or simplified approach to EA is on people’s minds: Pragmatic Enterprise Architecture Framework (PEAF) and the “Good enough architecture methodology“.
I have found another even closer to home: a local company [disclosure – I work with these folk from time to time. Putting my money where my mouth is, I guess] called Fragile to Agile who have developed a framework that can be applied consistently from the highest level of abstraction (business operating model, business capability model) through strategic project prioritisation all the way to system design and development – which means (subject to application at all levels) the framework can give traceability from a piece of code to the desired business outcome it supports, and identify any gaps in that support. The thing I like about it is that it isn’t necessary to implement the framework at all the lower levels to get value: a relatively short engagement can give the business an operating model decision and capability model that informs strategy discussions. From that point of demonstrated value, a client can choose to extend the framework to the next level of definition (e.g. “building codes” for application deployments), and so on down the stack.
Is it perfect? It isn’t as comprehensive as say, TOGAF – but that’s not a bad thing. Perfection, like beauty, is in the eye of the beholder … in this case the client, who potentially sees value quickly and can build on that value iteratively and at a pace of their choosing. I doubt that it’s the only “practical” framework out there – as I noted earlier, EA is looking for shorter paths to value for its constituency.
It’s not too bad for me – I didn’t have to travel far to find an architectural approach that made sense and had a healthy serve of practicality to it – while the objectives (the “what”) of higher-ceremony ideas are great, the execution (“how”) can sometimes look like a “death march” project. My preference has always been for the agile, iterative approach to solving problems and building capabilities … Fragile to Agile isn’t called that by accident.