One of the biggest reasons there is so much bad software is that business schools pump out people who have been led to believe that the ability to draw diagrams is an acceptable substitute for the ability to read a line of code or assess a technical standard.
One prominent victim of this phenomenon is the whole area around enterprise architecture. Gartner calls it:
...the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution
It's a clear enough definition and - as with everything Gartner - it doesn't help anyone accomplish much of anything. Not counting the dubious objective of creating a market for MBA graduates.
Here is my alternative definition of Enterprise Architecture. You are free to use this definition for any purpose, especially if you intend to tattoo it on your CIO's backside:
The systems we are responsible for are legion, they are heterogeneous, they are wicked, and they conspire. We wield the autocratic staff of Enterprise Architecture and it sheds light and builds highways (and occasionally bike paths). It fosters empathy for the whole in the heart of each subsystem.
I am fortunate enough to have a employer who has an appropriate level of appreciation for the abstract notion of Enterprise Architecture, coupled with a sensibly low level of respect for established frameworks such as Zachman and TOGAF.
Look at this picture taken from the wikipedia page on the Zachman Framework. It shares structure and semantics with drawings scratched on cell walls in Guantanamo:
Where I work, we have overall governing and coordinating responsibility for a fairly large systems complex. Specifically, a big subset of the Danish national library systems infrastructure. It's a lot of systems, a lot of integrations, a lot of protocols (some quite esoteric, many derivative), and a lot of churn in the evolution of the individual components.
In human language, it's complex and it's driven by a lot of people and philosophies which don't all dance to the same tune. This is the mating call which draws the attention of the wielder of the Staff of Enterprise Architecture.
We needed a way to model the whole such that changes to one component does not cause another to launch any nukes. We needed a tool which allows us to conduct impact assessment of tweaking an integration protocol. And we thought it would be nice if the development plans of each component exhibited a form of technosocial cohesion; if ground-level development plans increased empathy for the whole rather than triggered firefighting in vaguely related subsystems.
As any good business consultant will tell you, we needed an Enterprise Architecture Repository. As responsible architectural autocrats who know what a Makefile is, we said bollocks to that and went the practical way
A real Enterprise Architecture Repository (hereafter EAR) is one which is sold in a cardboard box with the words Enterprise Architecture Repository Suite Deluxe Enteprise Edition. It is sold for amounts of money so vast that the base license includes the very souls of 10 to 15 fairly recent management school grads who will spend the next five years drawing diagrams and sending Visio diagrams to an Indian offshore development team who "adapt" (primarily, writing 1000 line stored procedures and building out God objects) the system to your organisation.
In the meanwhile, your systems go down the shitter.
Those of us who prefer an existence where systems don't go in the shitter take an alternative path. In our case, we have chosen to go with a Semantic Mediawiki.
Here is wikipedia's explanation of what Semantic Mediawiki is:
Semantic MediaWiki (SMW) is an extension to MediaWiki that allows for annotating semantic data within wiki pages, thus turning a wiki that incorporates the extension into a semantic wiki. Data that has been encoded can be used in semantic searches, used for aggregation of pages, displayed in formats like maps, calendars and graphs, and exported to the outside world via formats like RDF and CSV.
That was a big load of do-not-care. Let me translate it for you:
Semantic Mediawiki allows you to attach properties to wiki pages. And to query the pages based on these properties.
This isn't minor. This means that the only difference between a vanilla Semantic Mediawiki and an EAR is your ability to model your architecture in categories, properties, and templates. Our Mediawiki-based EAR is still under development and evolution, but we already have a base structure which does an astonishingly good job at modeling our EA.
Let me share some key notions from our Semantic Mediawiki structure and use cases with you.
We operate with the Semantic Forms extension. Strictly speaking we don't need it, but there is a certain elegance to comboboxes in forms which are automatically populated from Categories.
We define a page category for each unique entity in our EA. Here is a subset of our structure, with some examples of semantic linking:
Pages in this category represent each unique system in the collective, regardless of whether we govern it or not. A System page links to a Vendor page.
|Vendor||Pages in this category represent the vendors; the gatekeepers of change of the system components of the whole architecture|
Standards-setting organisation; includes pages on organisations such as OASIS or NIST or Library of Congress, but can also link to vendor pages
Things like SOAP, ReST, sneakernet, RFC 2459, etc.
Pages in this category are semantically linked to two pages under the category System, one Integration Protocol page, and one Integration Transport page.
|...||and so on|
For each page type, we define "interesting" properties. Our page template for System currently includes properties such as:
|Property||Attached to Category||Purpose|
The canonical URL to system source code.
The canonical URL to administrator documentation.
The latest version of the protocol
The date when the current version of the protocol was last bumped.
|... and so on|
And so on. Now the clever thing is, Semantic Mediawiki allows you to query your wiki based on these properties, and based on the connections between pages in different categories. Since Integration links to System, and IntegrationProtocol links to Integration, we have an automatically generated view on the IntegrationProtocol page which lists the systems that depend on this protocol.
This specific example is useful since it allows us as the Wielders of the Enteprise Architecture Staff to understand how a change in ine part propagates. It improves the empathy of the individual (single System or IntegrationProtocol) for the welfare of the collective (Enterprise Architecture).
As this EAR is in its early days, we are still using it internally for the purposes of seeding the data and stabilising the semantic model. In the medium term, we intend to open the wiki up to stakeholders. This includes administrators of some systems and vendors of others. We also expect to open the wiki to the public, albeit in read only fashion.
In the longer term, we will be looking at the possibility of creating some form of harmony between the vendors' software lifecycle toolchains (e.g. roadmap and development tracking systems) and this EAR. It's all a matter of metadata creating a semantic link between an issue in a bug tracker up through the semantic interlinkages to enterprise-wide context.
Our Semantic Mediawiki will continue to evolve and grow. We have painted a picture of our EA using categories, properties, templates, and semantic forms. It's still fingerpainting but it's lightyears ahead of commercial behemoths like Casewise Corporate modeler (yes, that is a real product name) in pragmatism, effectiveness, flexibility, and above all our ability to really own our EAR and wield it to tame the beasts in our systems portfolio.