BibSonomy ::  user :: cschie ::

Enterprise architecture is a management practice that was initially developed within the IT discipline to manage the complexity of IT systems, as well as the ongoing change constantly triggered by business and technology developments. Today, one of the primary reasons EA is adopted in organizations worldwide is to promote alignment between business requirements and IT solutions. EA is expanding into other business disciplines, as well: to enable business strategy development, improve business efficiency, facilitate knowledge management and assist with organizational learning, to name a few. In order to effectively implement EA in organizations, architects are increasingly looking for best practices and frameworks to assist them. One of the few architecture frameworks publicly available to guide architects in their implementation is TOGAF. Put simply, TOGAF is a comprehensive toolset for assisting in the acceptance, production, use and maintenance of enterprise architectures. It is based on an iterative process model supported by best practices and a reusable set of existing architectural assets. Since it was developed by members of The Open Group Architecture Forum more than 10 years ago, TOGAF has emerged as arguably the de facto standard framework for delivering enterprise architecture.

In the book The Art of War for Executives, Donald G. Krause interprets the following: “Sun Tsu notes, superior commanders succeed in situations where ordinary people fail because they obtain more timely information and use it more quickly.” For metadata professionals, this observation is increasingly relevant as more and more of the business seeks integration and federation, alignment with business goals and strategies, and agility - the ability to respond both quickly and accurately to change. Industry analysts and IT professionals are less focused on solutions to problems where metadata management plays a role but rather look more to metadata management as an overall strategy for the benefits it provides to multiple aspects of the whole organization.

TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership. The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise. Confusion often arises from the evolving nature of the term "enterprise". An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units. The business operating model concept is useful to determine the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there is often much in common about the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.

Open source is ready for EDW. Because open source is designed to be modular, an enterprise can start with one piece - say ETL or reporting - and can add on as needed. For comparable power and features an open source solution in this arena can cost 10 to 20 times less than a proprietary product. Whether large or small, companies today are being asked to do more with less. With open source, you can have an EDW without compromise.

For those of you that could not make it, I wanted to give you the gist of what I presented.  This presentation covers the evolution of the business rules technology focusing first on the drivers that forced the market to shift its focus from Business Rules Engines (BRE) to Business Rules Management Systems (BRMS).  In a nutshell, the main ideas are summarized below.  In a few days, the recording will also be posted on our community site for your convenience.

As the link between business and IT strategy, the enterprise architecture outlines the framework for IT solutions. The EA describes IT structures, standards, processes and shared corporate services. The task of an EA is to support the business areas and IT experts in shared planning processes and in the comprehensive further development of the IT architecture. Detecon decided to use TOGAF from Open Group as an open and widely accepted standard as basis for our architecture work. A comprehensive experience from successful projects at customers with different size and industry demonstrates the benefits of that strong methodology. Based on TOGAF basic structures, Detecon enhanced the methodology in different areas, e.g. the finance and controlling, business cases, governance or SOA migration strategy, and applies those successfully. Detecon trains architects in the TOGAF framework with the following goals: To accelerate architecture development at their companies To reduce complexity in planning heterogeneous best-of-breed systems To secure the implementation of all requirements To ensure security for the future To provide a tool for improved communication of goals and strategies for business units and managers.

TOGAF 9 encompasses the entire enterprise architecture life cycle, which is important as architecture is a never ending journey, always changing and evolving. The figure below depicts the TOGAF Architecture Development Method (ADM) which covers the entire architecture life cycle.

The Open Group released TOGAF 9 earlier this month. All the details are available on the Open Group website for those who are interested. This post briefly shares the highlights and differences but is not a complete indepth analysis. Version 9  builds on Version 8.1.1 with quite a bit that is new and is a significant milestone for TOGAF. It now comprises seven parts: Introduction Architecture development method (ADM) ADM guidelines and techniques   New! Architecture content framework    New! Architectural reference models   Architectural capability framework    New!

The Open Group Architecture Framework (TOGAF) is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization (see Conditions of Use). TOGAF is developed and maintained by members of The Open Group, working within the Architecture Forum (refer to www.opengroup.org/architecture). The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense (DoD). The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM, which itself was the result of many years of development effort and many millions of dollars of US Government investment. Starting from this sound foundation, the members of The Open Group Architecture Forum have developed successive versions of TOGAF and published each one on The Open Group public web site. If you are new to the field of enterprise architecture and/or TOGAF, you are recommended to read the Executive Overview (refer to Executive Overview), where you will find answers to questions such as: What is enterprise architecture? Why do I need an enterprise architecture? Why do I need TOGAF as a framework for enterprise architecture?

ebruary second the Open Group released a new version of its framework TOGAF 9. TOGAF started out as a Technical Infrastructure Framework, started by the US Department of Defense in 1995 with TOGAF 1, and has grown out to a full framework for enterprise architecture in TOGAF version 9. So why do you need a framework like TOGAF 9. From its origin IT was introduced to speedup business process so companies could make more money faster. Somewhere along the way IT became a technology driven, self sustaining machine where we all needed more gadgets without contributing to the added business value. Enterprise architecture is one of the ways to get the primary goal of IT back within normal costs and in control for a organization.

The image above show the segments or classification of these standards. By asking basic questions such as How, What, When, Who and Why we can also simplify this a bit. Starting from the bottom up lets talk about what was discussed and I'll add some of my thoughts as well.

Das Zachman Framework ist ein 1987 von John Zachman konzipierter domänenneutraler Ordnungsrahmen zur Entwicklung von Informationssystemen. Es bildet dabei einen Leitfaden, der Vorschläge enthält, welche Aspekte aus welchen Perspektiven Berücksichtigung finden sollten, um die IT-Architektur einer Unternehmung erfolgreich aufzustellen. Mit Hilfe dieser Modellierung kann sowohl die Dokumentation- als auch die Planung eines solchen Projekts unterstützt werden, wenn bspw. nachvollzogen werden soll, welche Entscheidungen welche technischen Umsetzungen nach sich gezogen haben.

The Zachman Framework is a framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise. The Framework in practice is used for organizing enterprise architectural "artifacts" in a way that takes into account both: who the artifact targets for example, business owner and builder, and what particular issue for example, data and functionality is being addressed. These artifacts may include design documents, specifications, and models.[3] The Framework is in essence a matrix,[4]. It is named after its creator John Zachman, who first developed the concept in the 1980s at IBM. It has been updated several times ever since.[5]

CEP module receives or intercepts a flurry of events and processes them with the objective of figuring out what those events are relevant for; it triggers the appropriate business processes or decision services BPM module receives the request for a given process to be applied to a higher level entity (an application, a document...); it automates the steps defined in the business process BRMS module is invoked with a given context to apply business rules; it makes a business decision 

Substitute a standard web services interface for a speaking tube, a business rules management system for his encyclopedic knowledge of policies and regulations, data mining or predictive analytics for his customer knowledge and adaptive control for his experimentation and you have Decision Management. The Answerer but on an industrial scale.

at the core, enterprise architecture is very simple: it starts with the idea that one should plan technology purchases and development ahead of time and -- here's the important part -- that the business people, not technology people, should determine what is needed (the requirements).

The MS Rules Framework was a spirited attempt by MS to create a wide-ranging environment that could integrate rules held in different forms in different repositories, mange the deployment of rule sets out across an enterprise environment and even target a range of different rules engines.

Every organization has 4 other domains in which BPM projects are executed; Corporate Performance Management (CPM), IT architecture Management (ITAM) and Governance Risks and Compliance (GRC), Core Application Framework (CAF/SAP). The Enterprise BPM framework can be also used in all these domains, which results in 5 maturity models including the ERP/SAP maturity model (see figure below).