Home › Business › Toolsets for enterprise-architecture – another try

Toolsets for enterprise-architecture – another try

Posted on Posted in Business, Complexity / Structure, Enterprise architecture, Knowledge 4 Comments Tagged with , , , , , , , ,

What tools and toolsets do we need, to support our work in the architecture of the enterprise as a whole?

The short and more cynical answer is “Not what we have right now”. To be blunt, maybe none of the current ‘enterprise-architecture’ toolsets are fit-for-purpose, for the work we need right now to do as architects of the enterprise itself.

(Fit-for-purpose for some parts of the work in some cases, maybe yes; but for the work as a whole, no. And since almost none of the toolsets will talk to each other – and in many cases are designed to prevent that happening, and instead each attempt to enforce its own proprietary ‘walled-garden’ –  they’re now often more of a hindrance than a help in making sense of the whole-as-whole. Bah.)

The real problem is that the core premise for most of those toolsets is at least a couple of decades out of date. Back when they were designed, ‘enterprise-architecture’ was a misleading term that actually meant ‘architecture of enterprise-wide IT-infrastructure’ – which was, yes, a significant problem for certain large organisations of that time. For that kind of ‘enterprise-architecture’, Zachman’s oft-repeated assertion that “Architecture for airplanes, ships, chairs, buildings, it’s all the same – why should it be any different for enterprises?” almost did sort-of make sense. (Sort-of. For a given sense of ‘Sort-of’, anyway.) Hence the usefulness, for that problem, of toolsets that could document all the relationships and interdependencies of a large organisation’s IT-estate and all the applications and data that might depend on it.

Yet the reality is that, however complex it might be, IT-infrastructure is merely one small part of the enterprise as a whole – and at that, often by far the easiest part of the overall complexity of that enterprise. And to make it worse, many of the toolsets are designed only to provide some form of static document, a snapshot of that IT-estate at just one given moment – with little to no support to guide us through the sheer messiness and dynamics of change. The one place where we most need help, they give us no help at all.

So, to put this the other way round, there’s a huge unaddressed need for toolsets to help in design, development and dynamic change of all aspects of ‘the architecture of the enterprise’. Toolsets that help us with the core aim of all architectures, that ‘things work better when they work together, on-purpose’. Toolsets that will work the same way, consistently, across every context, every type of content, every scope, every scale, every level of granularity, every level of implementation, every level of complexity – and hence bring to an end the fragmented mess that we have right now of toolsets that merely make worse the relentless ‘dotting the joins‘ throughout every stage of Damien Newman’s ‘the Squiggle’:

To get out of this current mess, all we need to do is apply a bit of architecture to architecture itself. And as we do that, it should become clear that there’s a huge market-opportunity right now for anyone who can make this work.

In a sense, it’s not even about toolsets as such. Instead, the real need is for a platform that links all of the tools together, across every part of the toolset-ecosystem and toolset-workspace. Almost by definition, that platform itself cannot be proprietary: it must be open, it must be shareable by all – otherwise it cannot achieve its purpose of linking everything together. This is one place where the Open Group’s tagline of ‘Boundaryless Information-Flow’ really does make sense.

(Note, though, that an open platform doesn’t mean that everything has to be open: there’s still plenty of room for proprietary toolsets and suchlike, if that’s what people really want. As long as those proprietary toolsets do support this very real need to link everything together, then everything’s fine. Probably.)

I’ve been working on this problem for well over a decade now: but I’ve had to accept that I’m not the right person to do it. At the very least, it’d need a real master of software-development – and my days for doing that are long since gone. It’d need a master in user-experience development – which I’m not. It’d need a true master of marketing and suchlike – which I’m definitely not. And perhaps above all, it’d need a great team-lead – which I’m, uh, also not. Oh well…

But if it’s not for me, could this be for you?

And whoever does take up this challenge, I believe that what I’ve done so far could definitely help. As I say, I’ve been working on this for over a decade, documenting pretty much every step of that work as I went along. Hence all of the links that follow – all of which document different aspects of what’d be needed to make this platform work.

I’ll admit there’s a lot of it: almost fifty posts right there, with plenty of further material crosslinked in along the way. To be honest, it’d probably take you at least a couple of days to read just these posts themselves – maybe more like a week if you follow up on all of the link-trails and cross-references. But even that would be a trivial investment of time if you have any interest in creating toolsets for enterprise-architecture that actually work in the ways that we need. And I do believe that there’s just about everything you’d need right there to form the basis of requirements and more for the overall purpose and for its implementation.

(In the sections that follow, I’ve listed the posts in date-order, so that you can see how the ideas have developed over the years.)

First, a few posts on what we might describe as Integration – a set of overviews that bring it all together:

Next, a decade’s-worth of explorations in the ‘Why‘ behind the need:

Then a few forays into the ‘How‘ – about how this blending of toolset and platform would be used in real-world practice:

Some examples of the ‘What‘ that we’d need to cover across the whole-enterprise space, in terms of notations and the like:

And, to finish, some practical notes towards Implementation – getting beyond conjecture and towards making it real:

(There’s also one more post – More metamodel stuff (26 May 2009) – that was a pointer to a bunch of metamodel descriptions on a self-hosted wiki I ran for a while at ‘ea.openfutures.org/OsEATools’. Unfortunately the wiki is now broken and no longer accessible, but I think I can dig up the content from somewhere if anyone really wants it – perhaps let me know if so?)

Now, over to you: the time is ripe for this – so somehow, between all of us, can we make it work this time?

Related posts:

  1. The toolset-ecosystem
  2. Guess I could do with some help here…
  3. More on that enterprise-architecture ‘help needed’
  4. Helping others make sense of my work
  5. Towards a whole-enterprise architecture standard – 5: Practices and toolsets

4 Comments on “Toolsets for enterprise-architecture – another try”

  1. Hi Tom, Could you please “dig up the content somewhere” because I would really like to have the complete picture of your thoughts in responding to your call to action here?

    Reply

    • Hi there – found it. Have sent it to you via email.

      It’s only about four pages (though fairly dense), plus one Visio graphic that lays out a data-model that uses a hardwired Zachman-type categorisation-structure that I wouldn’t use these days. And do bear in mind that it’s from almost a decade ago (May 2009), and much of it may/will have been superseded in later posts – but it’s there for completeness, as you say. 🙂

      Hope it’s useful, anyway!

      Reply

  2. If you look into an “real” ARCHITECT’S you’d see that designing a skyscraper is messy, an Aerospace Engineer’s office, is anything but straight forward. Its the misinterpretation of the Zachman Framework/Ontology and how Architects really work that leads to thinking is a straight once through path. Rarely does an engineer or architect have a single solution, often there are models to evaluate for the best choice and then changes when a client’s needs alter or become more clear.

    Reply

    • Yep, strong agree on that, Brian. It’s one reason why I emphasise that the Squiggle, useful as it is as a description of the path from messiness to certain-enough-to-build-on, it doesn’t give us the other key part of the picture – that it’s iterative, recursive and more. Which means that the seeming-certain falls back into the messiness again, time after time. Hence tools that assume that we’re only going to work with a one-shot (or, worse, only ever the certainty-bits) are not so much not-much-use, but actively misleading in terms of how the real process actively works. In that sense, yeah, dear old John Z has much to answer for… 🙁

      Reply

Leave a Reply to Tom G Cancel reply

Your email address will not be published. Required fields are marked *

*