It used to be easier to describe when I was programming code – while lots of people couldn’t understand what I wrote, the concept was easy enough to grasp.
Over the years, though, I’ve moved up the abstraction chain, and while in some ways the tools themselves are easier for people to understand (think words, and boxes and lines) the concepts are harder to explain.
At the highest level of abstraction, what I do is called enterprise architecture, which has become something of a loaded expression with some bad reputation to overcome – but it’s still the correct term for much of my work. If you Google the term, you’ll probably find a lot of different definitions, most of which are at least partly accurate, some of which are just plain wrong. There is also some scope for definitional differences between those practicing it, which doesn’t help.
If I want to avoid the religious wars, all I can do is describe what I see as enterprise architecture, and hopefully in a way that helps you as well.
First – while enterprise architecture (and now I’ll start using the popular abbreviation EA) is about how, where and why technology is used in an organisation, it’s a business discipline, not an IT thing. If you like it’s the business “dog” that wags the IT “tail”, rather than vice versa. While it IS possible for benefit to be found with an IT-focused EA project, it is narrower and less transformative than if it is business-driven. EA deals with all three legs of the business stool: people, processes and systems, and can help with job/role design, organisational structure, process improvement, and technology design.
EA when done well, equips an organisation to handle change, whether self-initiated or coming from its operating environment. The aim is agility, or adaptability. In something of a paradox, my favoured EA approach seeks to describe a stable basis for building on …
- a definition of the functions that the organisation performs, or is responsible for
- its preference for standardisation of business processes and their integration between business units
- its desired business outcomes.
From that base, it is possible to analyse what the business does now and how well that fits their purpose, describe a desired target state of play, and draw up the technology roadmap to traverse the gap. This provides a yardstick against which any proposed project (not just technological) can be measured for its support of stated outcomes and/or key business functions. It can provide an ongoing framework for prioritising projects, and ensuring that what gets done has a clear reason, and meets a defined set of technology principles … what the business books call governance.
There’s often a considerable effort in putting together those base documents and models (and subsequently building on them); and that’s what I do … it’s sometimes referred to as “town planning for technology” because it looks at the whole technology landscape for an organisation, rather than at specific systems (the technology principles mentioned above are an interesting parallel to “building codes”). It describes a technology landscape without specifying specific technologies, but provides principles and guidelines, based on the outcomes you want, to guide technology decisions.
I also still play further down the abstraction chain sometimes: defining data models and designing solutions to meet specific technology requirements – to stretch the building analogy, it’s designing the individual constructions that fit into the town plan. That’s an exercise that is always easier to do well if the enterprise architecture is already in place, but it’s not impossible to apply some of the principles in the absence of a formal EA …
I mentioned my favoured architectural framework earlier: it’s called Fragile to Agile, and I’m currently working with its owners to become more familiar with it, in preparation for licencing it for independent use. You can find some more details about it on their site.
Related articles, courtesy of Zemanta: