Frustration leads to innovation

That (part of) the problems outlined in my contribution "Release or relationship management" was recognizable for a lot of people as came clear from the responses I received. I don’t pretend to have the right and appropriate solution but asked attention for a number of shortcomings. So a the invitation of Wilko Fisher, owner of ValueBlue, I discussed this issue with their Enterprise Architects. The additional insights seem to me a justify for part 2.

During this "pizza session" there were discussions on a number of possibilities to provide IT visibility. One such possibility is the Enterprise Architecture discipline which models are used to describe IT. A picture is finally telling more than 1000 words so it provide you quickly with insights. Subsequently, these models should allow us to model a future state which are then translates into architecture principles.

Measure or modelling
Many popular Enterprise Architecture tools, however, have little ability to connect to the available tools used in infrastructure. Most even the role of infrastructure management (service support) is ignored what is remarkable because without well-managed infrastructure everything stops. At best, reference is made to the information stored in the CMDB. Modeling by assumptions, there is a certain risk that the baseline is not correct. This makes these models is at best a simplified representation of reality.

As the technology is now so fast architectural models are sometimes outdated before the ink is dry. This explains the architecture principles are often seen as prescriptive and obstructive by service support. Architecture sees infrastructure and associated management as concern of the implementation level and exclude it in its models. Occupational, more than a sufficient basis for serious problems and additional costs.

Efficiency at all levels
Those who connect Enterprise Architecture to many infrastructural management tools reach an insight that is closer to the truth. Because through various changes in the infrastructure most organizations can no longer rely on the information in the CMDB. The comment by Cogmios on Release or relationship management is correct as there are several assumptions or perspectives. And the main reason why the alignment of IT with the business is so difficult is in the many repositories used. Technology doesn’t align IT to the business but people and process do!

The language barrier between the layers, where infrastructure management is often "hexadecimal" whereas the business thinks 'binary', creates mutual tension and frustration. Who models based on assumptions sees the glass half empty, but if you look at the numbers of the infrastructure know that it is half full. In this way, the architecture never is a quilted patchwork and result of many changes is just a shift of CapEx to OpEx, and thus only an accounting profit.

Fear is a bad advisor that many (technology) suppliers use. But with ignorance about the infrastructure the same errors like wrong changes, unnecessary use of resources and poor Root Cause Analysis keep leading to waste and frustration. Continue along the path of pushing more technology as answer will ultimately not solve this problem. By connecting infrastructure management tools with Enterprise Architecture there will be be more visibility. And with visibility you can make better educated decisions.

Intellectual Property or Proprietary
In all layers of IT tools are deployed with unfortunately often focus to a specific goal. Regular suppliers of these products thereby throwing all kinds of obstacles to make exchange information more difficult. Intended to protect the intellectual property, proprietary databases, and encryption schemes are use for example. As previously PaVaKe responsed to the article ‘Release or relationship management’ this is the reason many repositories exist. And if there is some exchange between them it remarkably need a human interface in the form of a consultant.

If the entire IT organization takes a better look at their needs, it might be possible to break with this. But selecting tools at their reusability require we look a little bit further than the "beads and mirrors" of the user interface. If data is easier to exchange it can also easily be used to enrich Enterprise Architecture. Unfortunately most solutions cooperate poorly and we can only choice for a modular expansion of previously established tools from those technology suppliers.

Finally
Previous article "Release of relationship management" is written from a number of examples not exhaustive within the infrastructure. With all the new delivery models this infrastructure is now more a movie than a photograph. The term hacking might get in earlier article a negative tone and deserves a little adjustment. A hacker is also someone who is creative and unorthodox to escape technical limitations.