“ Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate”
“ A logically consistent set of principles, practices, policies, models, standards and guidelines that are derived from business requirements, that guide decision-making and the engineering of an organization’s information systems and technical infrastructure.”
A general Enterprise Architecture (EA) framework provides general high-level views for the separation of enterprise level concerns for use in any industry or project. In effect, the EA aims to provide the ability to view complex systems underlying organisations from a high-level to aid in analysis and understanding during strategic planning.
The Zachman Framework first published in 1987, defines a logical structure for the classification and development of specific models (i.e. design artefacts) required in the management and operations of enterprises, including the development of supporting enterprise information systems. Together the inter-related models in the framework separate enterprise specific concerns (e.g. function, data, network e.c.t.), providing a holistic enterprise.
The Treasury Enterprise Architecture Framework (TEAF) is framework developed specifically for the U.S. Department of the Treasury and its bureaus in order to aid in performing strategic planning / investment management, and to provide direction for the development of enterprise architectures tailored to the needs of the U.S. Treasury Department and its bureaus. The framework had been developed with the Federal Enterprise Architecture Framework (FEAF) and Zachman Framework as its basis
Originally designed as a way to develop the technology architecture for an organization, TOGAF has evolved into a methodology for analyzing the overall business architecture. The first part of TOGAF is a methodology for developing your architecture design, which is called the Architecture Development Method (ADM). It has the following nine basic phases:
Preliminary phase: Framework and principles. Get everyone on board with the plan.
Phase A: Architecture vision. Define your scope and vision and map your overall strategy.
Phase B: Business architecture. Describe your current and target business architectures and determine the gap between them.
Phase C: Information system architectures. Develop target architectures for your data and applications.
Phase D: Technology architecture. Create the overall target architecture that you will implement in future phases.
Phase E: Opportunities and solutions. Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D.
Phase F: Migration planning. Prioritize projects and develop the migration plan.
Phase G: Implementation governance. Determine how you will provide oversight to the implementation.
Phase H: Architecture change management. Monitor the running system for necessary changes and determine whether to start a new cycle, looping back to the preliminary phase.
Manugistics Product Data Mgmt/Demand Planning ISVs, Build Vertical / Company Specific Unix, VAX, AS/400 IBM Mainframe… Legacy SMB ERP… ERP Vendors, I2 Connecting Partners (SCM) MS CRM, Salesforce.com Siebel, SAP Front Office (CRM) Axapta, Great Plains SAP, Oracle, JDE, Manugistics… Back Office (ERP) Small to Medium Enterprise Category
What is SOA? SOA is an emerging paradigm to integrate systems, applications, processes and businesses. SOA delivers differentiated business capabilities or products through the assembly of autonomous business and technology capabilities (services). SOA changes the way an enterprise is run by making the business process the focus.
1) Boundaries are Explicit - Crossing boundaries is an expensive operation as it can constitute various elements such as data marshalling, security, physical location, etc. Some of the design principles to keep in mind vis-à-vis the first tenet are
2) Services are Autonomous - Services are self contained and act independently in all aspects such as deployment, versioning, etc. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves.
3) Service Share Schema and Contract, not Class - Services interaction should be using policies, schemas and behaviours instead of classes which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using a XML schema), message exchange patterns also known as MEPs (defined in WSDL)
4) Service Compatibility is based on Policy - At times one cannot express all the requirements of service interaction via WSDL alone, which is where policies can be used. Policy expressions essentially separate the structural and semantic compatibility. Or in other words, “what is communicated” and “how/whom a message is communicated”.
Service-Oriented Business Applications Auditing and Logging Monitoring & Detection Authorization & Access Service-Oriented Infrastructure Configuration Design & Modelling Service-Oriented Implementation Service-Oriented Integration Orchestration Workflow Application Integration Existing Systems Publication & Discovery Service Management Metadata Management Svc Dev Environment Service Provisioning Transformation & Routing Host Integration Service Repository Code & Testing Management & Governance Lifecycle Process Service Publishing Service Standards Hosted Svc Environment Transport Example of a SOA Implementation
Universal Business Integration Platform (Integration Journal Online, 2003)