Название: Tools and toolsets for enterprise architecture: Support for design, discipline and decision-making
Автор: Tom Graves
Издательство: Leanpub
Год: 2022-12-19
Страниц: 466
Язык: английский
Формат: pdf (true), epub
Размер: 10.2 MB

This anthology from the Tetradian weblog explores a range of topics about the kind of toolsets that we need to support the work in enterprise-architectures and the like.

It includes around 50 posts and 90 images, and is split into five sections:

Toolsets: Integration - a set of overviews that bring it all together
Toolsets: Why - a decade’s-worth of explorations in the ‘Why‘ behind the need
Toolsets: How - about how this blending of toolset and platform would be used in real-world practice
Toolsets: What - some examples of the ‘What‘ that we’d need to cover across the whole-enterprise space, in terms of notations and the like
Toolsets: Implementation - some practical notes towards implementation, getting beyond conjecture and towards making it real

Which is where we come back to the need for those core elements that I’ve been ranting about through all of these posts:
- a common file-format, or common content-structure, to share information between tools
- a database-structure that can hold that content within some kind of database-technology, such that editors can work on it
- a common way to describe ‘editors’ (tools) that can act on that content, in whatever way we need
- software apps that can support the content, the editors and the underlying data-structures, across the whole of the device-ecosystem from hand-helds to virtual-reality ‘war-rooms’

The crux of this - the one, core, inescapable requirement for this - is that all of these elements must be able to work together, as a unified platform, without being blocked anywhere by anyone’s ‘walled-garden’. If we don’t have that, it doesn’t work: we’d be stuck instead with yet another ‘dotting of the joins’ within the existing fragmented mess.

Sure, there are variants of all of those that sort-of exist already, in myriad forms. But in current implementations, again, they each only cover one small part of the space, and they don’t work together - and that’s the whole point, the whole problem. For example, when we look at the file-format, the content-structure:

- it’s sort-of like HTTP MIME-types - it has to be able to reference any type of context
- it’s sort-of like what we could do in a SQL database - yet it needs to be accessible, storable and sharable at a literally global scale
- it’s sort-of like what we could do in a graph-database
- it’s sort-of like what we could do in document-database
- it’s sort-of like Git or Subversion, in terms of version-control and rollback
- it’s sort-of like OWL or RDF, in terms of support for ontologies and semantics
- it’s sort-of like a wiki - some aspects of it, anyway, particularly readability, editability, versioning and rollback
- it’s sort-of like a topic-map - yet one that needs version-history and access-control as well
- it’s sort-of like DNS, in that we’ll need to be able to translate a true unique-ID into something more accessible and meaningful
- it’s sort-of like Java namespaces, in that we’ll need to support contextualisation, yet whilst still supporting truly-global connectivity
- and so on, and so on…

The catch, of course, is that no single one of these ‘sort-of like’ examples would be enough: it needs to be able to support all of those things, and more. All in the one structure, that we can move between any tool to any other tool. Which doesn’t exist. Not yet. Not in any non-proprietary form, certainly - which it must be, for this purpose. That’s the problem; that’s the reason for working on all of this.