In many ways, Enterprise Architecture (EA) is as misunderstood as Semantics. Although EA has been practiced across a much wider community of IT professionals for a longer period of time, it still suffers from an identity crisis. Is EA the mandatory precursor for model driven development, or is it part of a bigger picture and if so, what is that picture?
It is my contention that the reason Enterprise Architecture is still misunderstood in many quarters and often unsuccessful in practice is precisely because it does exist within the context of a larger picture. All too often, that larger picture is simply ignored leaving those executing EA projects somewhat perplexed as to find meaningful ways to make their efforts relevant to the organization sponsoring their efforts.
Enterprise Architecture represents a practices, tools and techniques which have evolved to help define the nature and state transitions of an organization from an IT perspective. The business view of the enterprise is of course included within this perspective but EA at its heart is and always has been driven by technology. The EA perspective is of a virtual entity, perhaps even the cyber-identity of an organization.
This view allows those who manage and maintain complex system of systems ecosystems through exploitation of a holistic characterization of all capability elements. However, like most things in IT, EA as a discipline suffers from a lack of clarity regarding its core principles and approaches. In other words, there is no agreed upon definition for any aspect of Enterprise Architecture right now.
Seeing the big picture, an example of placing EA’s within a real-world context
So, Semantics and EA come together on many different levels; first in the need for one to clarify the other, secondly in the ability to build that larger context and big picture view of where EA fits along with all of the other aspects of IT. To understand the complexity of the problem, it is worthwhile to capture some of the competing definitions that one current finds associated with the term “Enterprise Architecture:”
- Enterprise J2EE Architecture – This has been formalized within the curriculum and certification paradigm of the Sun Java Enterprise Architect designation. [http://www.sun.com/training/certification/java/scea.xml ]
- Federal Enterprise Architecture (FEA) – This has been defined by the Federal Government and supported through certification paradigms.http://www.enterprise-architecture.info/EA_Certification.htm
- Department of Defense Architecture Framework (DoDAF) – A wholly separate framework paradigm from FEAF.
- ToGAF, Zachman Architecture Frameworks – Commercially driven approaches.
- Unified Modeling Language – Often included within the context of other approaches but also often used standalone to manage EA efforts.
- Agile Enterprise Modeling & Architecture – Much more application development focused, generally less formalized than strict UML.
- Other Technical Specific Architecture – This is a long list and can include things such as .NET, Web 2.0, and literally 100’s of other software products.
- Service Oriented Architecture – This often now is bundled with business modeling using BPEL.
- Semantic Architecture – Yes, there a few people using this now although mostly within the context of semantic web technology or pure Ontological development.
What then is Enterprise Architecture, really? Is it a framework or set of frameworks, is it product specific skills, is it language specific skills, is purely technical or partially business focused, is it the metamodels and notation language used to characterize design?
Semantics allows us to integrate Systems & Architectures
The simple answer is that EA has been and will be what it needs to be to those who need it. There is no one approach now because no one approach will handle all of the related duties that architects are saddled with. The more important question has always been, will we find a way in which we can coordinate the various types of EA activities. This is an exact corollary to the questions that helped launch EA as a discipline (of set of disciplines) some twenty to thirty years ago. At that time pioneers in EA were looking for a way in which they could combine and coordinate the complexity of their systems environments. So, now it seems that EA has lead us to meta-integration. And what is the one approach we now have to tackle the problem at the top of complexity pyramid – Semantics.
– copyright 2008, Stephen Lahanas