Need a Reference

Yesterday my colleagues and I were talking about Enterprise Architecture (EA) isn't just about classifying metadata but rather it is more than that. I agree that statemenr. By classifying systems, processes, data, applications, resources, technologies and other aspects of your Enterprises, we begin to understand our enterprise but it also defines a reference point from where we can understand the architecture.

Defining the reference point is key but how do we define it? Usually having some requirements that the architecture is trying to address or solve is a great place in defining your reference point. If we are trying to optimize the inputs and outputs of a system then the architecture is going to focus on the inputs and outputs of a system rather than the internals of the systems. After defining where the reference point is, we need to define the reference point. This is not a easy task since the point could a be a subsection of a system (compononet), type of of subsystem (aspect) or a combination of (collection of components or aspects). A good starting point is have your original requirements and now you look at various architecture frameworks to see if these frameworks meet some if not all of requirements. You can also create your framework by stitching together a collague of frameworks. The secret ingredient in selecting your framework is to understand if they really meet the requirements and you, as an architect, can defend your architecture.

These principles are true when you are designing a complex ontology, a metamodel or even a process. In data architecture, we can literally derive infinite relationships between data entities and attributes but in the end does your data architecture must meet the requirements and address the problems. Data relationships can jusitified in a relational database model, metamodel or a class model however all these models should compliment each other and should not contradict each other. To understand if these models are truly complimenting each other and not contradicting each other, you need to have a reference point. The reference point should address the following:

• Does the Architecture address the requirements?
• Does the Architecture capture granularity at the correct depth?
  
• Does the Architecture validate in various use cases and scenerios?

Hope this blog blurb helps you to be a better architect.