Enterprise Architectures..
I have been working around EA and EA tools for the last 6 years, it has been interesting to say the least. I know that EA can cover a broad spectrum of areas so I will for the sake of this blog just stick with the DoD stuff. The DoD has a framework that is uses called DODAF. The DODAF or Department of Defense Architecture Framework is essentially guidance for military architects. The area that I have spent most of my time working in is in the tools that architects use and the data that they create. The idea that you capture a moment in time in an operational scenario or technical views and express these in images, documents or spreadsheets that are common is what these architectures are for. Sure it is more complicated then that but for the sake of this writing I can leave it at that.
When I started working on EA in the DoD it was all about the products. The products are used for analysis or review or to help make decisions, there are a number of reasons to have architecture products. There is no doubt that we need military architectures. Almost all organizations have architectures, as a matter of reference, I don’t know of any organization without them. The need is there. I can’t talk about the organization I worked for so I will talk around it.
To build architecture products you require components, almost like when you are writing a book you need words. Some of these components could be used in multiple products. The idea was to become data centric and decouple the data from the products. This is the beginning of the rabbit hole. When you decouple data from the products you lose context. Even if you create data mappings across products the context of the product may not travel across the mapping.
The result of this idea was an increased cost in technology. You need more advanced tools, more data storage, more labor, more services, etc. All in the name of making things easier. What happened is that we spent more and spend more in EA than we need to. We created a vehicle for vendors to make money by fueling the EA tool concept. Data centric, net centric, SOA, service enabled, etc.
The idea that we can create common data repositories that are normalized for architecture creation is a good idea. The idea that we can consume data from multiple repositories and carry the context is costly and will continue to be costly. I have put a lot of thought to this and what I have come up with is follow the KISS principle. Get back to the basics. A friend of mine told me once that most products are based on lists. It is really that simple. Now that I have come full circle, I can see he was right. We need to get back to simple. More to come on that later….
The Cohenization Project 