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.

Practical Benefits of Architectural Views and Models

I have been assigned to lead a Services Oriented Architecture (SOA) prototype effort for the organization I work for. Since this project involves building a SOA solution with canned data sources (the easy part) and then formulating best practices in SOA governance (the hard part), I have begun to appreciate the skillset of an architect. IT Architecture helps folks, who are in the architect role, to create artifacts which can communicate the core IT system architecture, process architecture, data architecture, etc., etc, to various audience groups. Creating conceptual models and logical models provides a great mechanism to communicate complex or abstract ideas in a straight forward manner. IT Architecture doesn't simply involve drawing pretty pictures in Visio and show-off your Visio skills but it is more than that. It is the ability to take a system design, complex design and simplifying it to a diagram which conveys the necessary details to its appropriate audience. Being an architecture enables you to improve your communication skills, able to adapt and communicate to various audience in appropriate terms in appropriate detail. It is important to know that even when you are simplifying a concept for a technically novice audience, you cannot compromise the underlying physical architecture of a system. The architect has to know the whole design but then he is astute enough to decipher what is needed and what is not needed when the design is communicated to the appropriate audience. Anyway today I can say that I managed to convince key stakeholders in the project on how the system should be designed. This was a big accomplishment in the project. For any aspiring architects, you will miss developing code, you will miss updating your spend plan but in the end you will be responsible for marketing the system, improving the system and most importanly, communicating the system to the appropriate audience.

Technology Injection is bad!

You must of heard of Anti-patterns or practices which cause more problems in any Information Technology. Well here is one that I see in my current employment and I call it Technology Injection is bad. At my current employer, an average software development project has a duration of two to five years. The common problem with this approach is that new technologies are introduced or injected in the middle of the project cycle to address certain requirements. Is this a good approach? No! Since the new technologies are not researched well and they usually cause more headache since it also introduces new infrastructure, new skill sets associated with the technology, and it has a lasting impact on the project and eventually on the system.

Then the question comes up, "How do we address the problem of Technology Injection?"

The answer is that the system has be well architected which promotes loose coupling, well defined functional requirements, and not deviating from non-functional capabilities. Each architecture should be flexible enough for change but change would be done in a phased approach. If the architecture is not flexible then be sure to have those big yellow stickers which say in menacing black print, "LEGACY SYSTEM", since you might need to use them in five to six years. Like any IT approach, research and development (R&D) and thorough technology analysis need to be done to identify which technologies can be safely injected into the system.