What is an architecture? Well, let’s dissect that and see what we come up with. For starters, it is needed before we solve business problems, before we design and build systems and applications and before we put ‘things’ into production. If you build and deploy applications without an architecture, prepare for a long entrenched battle that threads through the realms of data, information, technology, and infrastructure. Saying that, I realize that most organizations do not have a formal architecture, but rather have general principles, standards and practices. This is one reason that IT is so challenging. Meeting agile business needs requires a dependable foundation of decisions.
An architecture is something that is addressed at the enterprise level. It is something that exists across the organization that enables an infrastructure (be it data, information, technology or infrastructure) to work together. So, in simple terms, an architecture is an enterprise wide agreed upon set of standards or direction. This implies that there is an overarching group that has responsibility across business and technical domains. And in turn this is enabled and actualized because someone, somewhere both understood and was able to sell the value of having a solid foundation.
Drilling down a bit further, the ‘agreed upon set of standards or direction’ really boils down to be a set of decisions. These decisions are made at all architectural levels; data, infrastructure, technology and information (to name a few important ones). These standards are in fact agreed upon rules of engagement that must exist. Further, these rules are derived only after a decomposition of systems (existing and non-existing) into its individual units. This decomposition is complete when each design orientation is at its most granular level. This is different for the different architectures.
The idea of an architecture is to break systems down to the specialist levels, so that these specialists can address the system (application) within their specific domain. Meaning, developers can receive requirements and think them through in the context of their specific architecture. And data folks can work from a common set of dependable rules of engagement that when followed across the enterprise provides them with a solid foundation on which to build, knowing that integration points, naming standards, metadata nomenclatures, taxonomies, etc. are there to rely on. The application folks can depend upon the architecture for proper building techniques, technology strategy, supporting documentation and so on. The information folks rely on the horizontal assurance that the right levels of metadata is in place and they anticipate the use of data to be consistent and so on.
So, an architecture is really a set of decisions that must be made across the enterprise, hopefully before the release of chaos (in the form of applications and system) at the most granular of forms so that it helps to manage this chaos from the bottom up as opposed to the top down. Managing from the bottom up is done via principles and standards, methodologies and best practices, governance and stewardship. Managing top down is just that, a downward spiral that is manifested by political infighting, protectionism, stagnation and a complete stoppage of the value chain (IT no longer can meet scope, costs, and schedules).
Happy architecting!
~ Scott Felten
Filed under: Architecture | Tagged: IT, Scott Felten, Architect, Cincinnati, Data, Data Architect, Information Technology, Architecture, Cost, Enterprise Archtiect, Enterprise Architecture, Management, Project Management, Schedule, Scheduling, Scope, Standards, Value Chain
