Review of No Magic MagicDraw with DoDAF Plug-in.
Planning, managing, and maintaining the evolution of the application landscape is a focal point of enterprise architecture (EA) management. Whereas, planning the evolution of business support provided by the business applications is understood as one challenge to be addressed in landscape management, another challenge arises in the context of traceability of management decisions. This article discusses the requirements regarding support for landscape management as risen by practitioners from industry, gathered in an extensive survey during which the tool support for EA management was analyzed. Thereby, a lack of support for this management discipline was discovered, which is caused by the way, application landscapes are modeled in tools. We subsequently discuss how to incorporate these requirements into an information model.
As global competition intensifies in the twenty-first century, companies large and small are struggling to find new sources of competitive advantage. As in the past, companies rely on information technology (IT) as a catalyst, enabler, and component of the new products, services, channels and business models necessary to compete in a global market. In many companies, the practice of Enterprise Architecture (EA) has become the standard to establish a coordinated view of an enterprise’s strategic direction, business services, and effective use of information technologies. However, increasing competitive pressures necessitate even higher levels of business alignment and agility than has been achieved in practice. This is particularly true for small and medium enterprises (SMEs) whose economic success in the global value-chain is highly dependent on their ability to quickly and effectively respond to dynamic market conditions. The integration of key technologies and methodologies, such as service-oriented architecture (SOA), model driven architecture (MDA), business process management (BPM) and internet-based computing, holds real promise to transform how IT delivers value to customers. The emergence and convergence of these technologies will also shape and influence the evolution of the practice of EA. EA frameworks and implementations that focus primarily on data and technology perspectives will evolve to a more process-centric framework to leverage a new class of technologies based on business services. Core to this transformation is the business process management system (BPMS) which will ultimately empower increasingly sophisticated business users to model the enterprise from design through implementation. The payoff is a new level of IT-Business alignment capable of delivering enhanced business agility and flexibility to effectively compete in an increasingly interconnected global value-chain.
Enterprise Architecture (EA) and methods for the design and employment of EA significantly contribute to the transparency, consistency, and eventually to the flexibility of an organization. However, there is hardly any “one-size-fits-all” EA method that is equally effective for a broad range of transformation projects or in a large number of different contexts. Based on an empirical analysis, this paper identifies three relevant EA contingency factors, three dominating EA application scenarios, as well as the correlations of both as a basis for a situational EA method engineering taking these differences into account.
This case study article describes the rationale for the development, use, and benefits of a metamodel to provide the underlying data model for Enterprise Architecture (EA) content. The case study uses the “EA3 Framework” (Bernard 2004, 2005) to illustrate these points. Metamodels enable integration among models and other artifacts that constitute most EA content. Integrated EA content enables repeatable and reliable analysis and reporting, mapping content to frameworks or reference models, and transitions among EA tools for upgrades or conversions. The initial publication of the EA3 Framework in did not define a metamodel or prescribe artifact content in detail. Artifact content and examples were added in the second edition of the EA3 Framework in 2005, including 46 artifact types that document the five layers and three thread areas of this framework. Though the relationships between the layers and threads were described in the 2nd edition of the EA3 Framework, this case study article provides the first detailed meta-model. The proposed EA3 Metamodel that is described in conceptual and diagrammatic form was developed to support the use of the EA3 approach by the author within a federal government agency using a bottom-up approach based on tool capabilities and reporting obligations. The metamodel described in this case study has been implemented using a commercially-available modeling toolset, and required no tool customization.