In these posts, we will examine the nature of Enterprise Architecture and the practical considerations as to why some work and others don’t. Ultimately, we consider ourselves strong advocates for this technique; however that doesn’t prevent us from taking a critical look at how the industry currently utilizes it and how the practice might be improved.
 |
| Enterprise Architecture can be viewed narrowly or can encompass all architectures within an Enterprise |
Perhaps the first and most famous example of architectural visualization in information technology is the Von Nuemann processing model. This was a logical representation of what later became a physical / hardware architecture in every computer ever built. However, before the hardware was designed, the conceptual approach to the management of the processing logic needed to be expressed. The original diagram was likely drawn on the back of a napkin or envelope but the medium was not important – what mattered was the ability to clearly visualize the concept and within that visualization to also illustrate the logical workflow.
Many of you have probably already heard countless analogies comparing the construction buildings and the use of blueprints to the development of systems utilizing architectures. To some extent the analogy is accurate, but there are some important differences. Those differences include:
- A degree of subjectivity in information systems not present in brick & mortar construction
- A degree of complexity in information systems not present in brick & mortar construction
- An assumption of a greater degree of interdependence and inter-relationships between virtual components as opposed to physical ones. (to some degree this is becoming less differentiated as more information systems are integrated into core building operational functions)
- The realization that the virtual system can become cognizant that it is integrated within a global infrastructure (buildings are more locally oriented).
All of the factors listed above tend to point to a singular conclusion – virtual entities are not bounded, either by time or space or by capability, thus their potential for harnessing complexity or becoming mired in it is exponentially higher.
Many people trying to get a handle on Enterprise Architecture make a mistake early on by focusing entirely on one or more EA frameworks. EA frameworks are self-contained architecture paradigms including data models, notation and methodologies designed to address various aspects of EA or specific markets. You may be familiar with some of them; the Zachman Framework, FEA, DoDAF, TOGAF. While these frameworks are important and for some practitioners will be dictated as mandatory, none of them represent the entire EA lifecycle. As is the case for many areas of IT, specialization has become too specialized at times, making it difficult to see the big picture. And not seeing the big picture in EA is one of the primary reasons that it is rarely applied to its full effect.
Enterprise Architecture is more than the visualization of a technical solution; it is also the visualized roadmap of the development and operational lifecycles associated with the solution. EA that is used only to meet a mandate or to support a high level business design or to support only a system level technical design will fail to place those elements in their larger context. To understand how EA can be used to transform the management of your enterprise information system environment we’ll need to look at EA from several core perspectives:
• EA as a unifying, organizational mechanism
• EA as design framework
• EA as interoperability framework
Copyright 2012 - Technovation Talks, Semantech Inc.
0 comments:
Post a Comment