As I’ve worked with several organizations over the years, I’ve noticed a wide range of concepts of what IT architecture is. More than once when I’ve asked for an architecture, I’ve been provided a simple block diagram that represented an application or data flow. Other times, somebody will give me a network connection diagram and call that their architecture. Actually, their answer isn’t wrong, it’s only incomplete.
An IT architecture is actually a collection of diagrams and documents which combine to describe the current state of your environment at a starting point. They add in any description of the evolution of your technology which will strategically lead you to your business goals. They also serve to mark a historical record of the evolution you have already made and the decisions which were made to get there. The latter is extremely important as future choices can use past research to guide the decisions where you may save the effort of re-investigating options that were already proven unfeasible. Or, they may also be used to re-evaluate whether a desired path may now be feasible based on technological improvements.
As you read this, you might be wondering why I’ve gone to such an elementary definition. Simple… in the coming weeks, I plan to dive deeper into the role of architecture in a world that is moving more towards agile, devops, continuous improvement and customer requirements driven. To best describe the role, we first must set a common definition of the component we are talking about. There are many who debate that IT architecture does not fit in the new paradigm, or that it might be in clear contrast with an agile environment. We’ll be looking deeper into that philosophy and I will demonstrate how they may actually support each other in a rapid-changing environment.
Ask Joe Geek 