dumdee

EA in HE

Posts Tagged ‘The Open Group Architecture Framework

EA & Principles

leave a comment »

Principles in an EA context

Erik Proper, Senior Research Manager, Public Research Center Henri Tudor, Luxemberg

Definitions

Identification of the problem statement to articulate the key drivers

Enterprises evolve and require controls to keep key business focus (cost, agility)

EA provides such controls but architecture today has deviated from this goal.

EA principles are general rules and guidelines. See Open Group TOGAF

A statement of the organisation’s philosophy of IS expressed in terms of its goals and business objectives. See PRISM for comprehensive definition.

A principle is a law, doctrine or assumption. Webster’s definition.

Scientific principle are proven in experiments, while normative principles cannot be proven but may be assumed as true.

Example of a scientific principle is the Archimedes law: any object, wholly or partially immersed in a fluid, is buoyed up by force equivalent to the weight of the fluid displaced by the object.

The use of architectural principles need to defined as either guides or laws, which much have been proven. That’s the difference between Proper’s Credo and Norm categorisation of principles.

Danny Greefhorst, Principal Consultant and Director, ArchiXL, the Netherlands.

How to do Architecture principles development using the cyclic assess, aim and act process

Identify the drivers – motivation for principles using the Business Motivation Model

[stakeholders goals and objectives; values – fundamental beliefs shared between people in a domain – credo; issues/challenges, risk and constraints, potential rewards]

determine

specify

classify

validate and accept

apply

manage compliance

handle changes

Practical processes include:

Generating the questions

Identifying principles that do not sit within the domain. For example, a manager’s idea and desire of managing data may not be categorised as an organisation principle.

Quality criteria to measure validity of principles using the 5 principles of the SMART technique:

Specific

Measurable

Achievable

Relevant

Time-framed – should be stable statements that can ensure times and management changes. That’s why is should not be based on one individual idea of a principle.

Observations from practice

Pure scientific principles that are useable in EA are hard to find

There is no criterion for determining whether a principle is a norm

It is the author that determines whether a statement is a requirement

Design principles are often not formulated

There remains a gray area between differentiating between architecture and design principles

Architecture principles should be a collaborative effort, iterative and explicitly linked to business drivers

They are used to determine downstream artefacts, compliance and stimulate discussions.

Architecture principles book due out in 3 weeks by authors, and Springer publishers.


Advertisements

TOGAF 9 Case Studies

leave a comment »

The Open Group Architecture Framework (TOGAF) ...

Image via Wikipedia

Vincenzo Marchese, Head of Architecture Capability & Performance, BP Oil International, UK

Tailoring the ADM to fit BP

The design review stage of the framework is one critical phase used in BP- drafting the stakeholder map process.

The design review must include stakeholder concerns.

(Possess an architectural review: reuse is more able knowledge and skills rather than the models). The role of the Lead Architect is to monitor the several projects taking placing, identifying their deliverables and ensuring they are consistent with the business goals. For reusability, each project at the plan phase has the option of searching through the ARK software installed on SharePoint to identify other project deliverables that may are reusable. Keeping track is done through the use of set KPIs for IT type projects.

The Architect’s Guide

Measuring the architecture value may be difficult to measure per pound spent but may be measurable through the project deliverables and timeliness of the projects.

Adopting TOGAF

Adopting TOGAF in BP came about the need to have a more rigorous approach to monitoring projects and developing capabilities in the organisation. The new CIO chose the best market approach.

Takeaways 

Training is only the beginning

Needs to be internally driven

Mean and Lean

Integrated with existing process models

Measure adoption using KPIs.

Optimising Architecture Evolution – A critical addition to TOGAF ADM

Rajarm Venkataramani, Cognizant, UK

Rob Oddy, Barclays, UK

EA brings clarity to strategic thinking in the financial sector. EA success is based on the drive of the business/product leaders adopting the concept of EA. Taking a top-down view by identifying the business strategy, then designing the architecture that supports the business goals. This then drives the execution of the proposed change. Most EA applications are centred around optimising platforms globally.

The CIO’s job is to be innovative, manage cost and speed delivery doing all of these within the parameters of the Chief Risk Officer’s policy and the governance framework. EA makes sense within these specifications as a tool to deliver business value.

TOGAF is about IT (services) and business strategy (goals). What about the products and operations viewpoints (customers)?

Written by dumebi11

May 11, 2011 at 11:40 am

ArchiMate on TOGAF

leave a comment »

Henk Jonkers, BiZZdesign

The famous archisurance company acquires two new businesses.

Typical IT landscape – Fragmented IT

Proposed change is to migrate to one archisurance crm system

Ingredients of an EA approach – to develop new processes requires a language to express the different viewpoints.

ArchiMate provides the flexibility to represent different viewpoints. It is a high-level modelling language with semantics and rules.

Modelling a domain, creating visualisations and relationships between domains. A basis for analysis (i.e. cost analysis), and instituting standards within the organisation.

Models can be expressed using different viewpoints for different audiences.

Models can be used to create catalogs of business services, systems, processes and their relationships. ArchiMate is used between three identifiable layers – business, application and technology. Vertically, there are information artefacts, behaviours, roles and structures that can be represented using the language. The new proposed extension is motivation of the model, which describes the stakeholder, concern (problem) and assessment (goal). There are requirement constrains that should be recognised, and principles to guide the proposed change.

ArchiMate Implementation and Migration extension

Covers the project, project role (business actor) and project result.

Preliminary phase – define the scope, team and principles. Principles can be defined such as business principles, data, application and technology principles.

Phase A – define the architecture vision, stakeholder analysis, goals and initial requirements.

Phases B, C, D – Getting the architecture right

Phase B – Describes the ‘as is’ state of the business, which covers the processes, services, and roles.

Phase C – Describes the application architecture , which covers the applications providing the interfaces for the customers. Includes baseline and target architecture. It conducts a gap analysis between both.

The communication application diagram and the process-application support can be used to describe the relationship between the business and application architecture.

Phase D – Describes the technology architecture. Conducts a gap analysis between the baseline and target architecture. Includes the application-technology support architecture.

Phases E, F, G – Making the architecture right

Transcending from the baseline to the target architecture. Creates the transition architecture A and B.

Benefits of ArchiMate

Used as a free-format and detailed solution architecture models

Creates a consistent and integrated modelling tool.

Tool for gap analyses.

How archiMate adds value to TOGAF

ArchiMate is designed specifically and integrated into TOGAF EA.

BiZZdesign looks into capability modelling. These can be modelled using business functions and artefacts from the business architecture.

See BiZZdesign presentation.

SOA on TOGAF

leave a comment »

Elements of a Service Oriented Architecture

Image via Wikipedia

Ed Harrington, Principle Consultant, Architecting the Enterprise

Dave Hornford, Co-chair of SOATOGAF Practical Guide WorkGroup and Chair of the Architecture Forum

Preliminary phase enhancements – first of all, assess the organisation has the capability to manage the enhancements.

The SOA Metamodel in TOGAF style.

How do you map SOA onto existing functions within the organisation?

SOA artefacts are showcased in TOGAF phase E, the solution architecture for applications that meet the business need.

Identify the core entities, functions that are key to the organisation and extend the requirements using SOA capabilities. Define your extensions, i.e. Information, IS Service Contract, SOA solution, Service Quality, Location (from the SOA metamodel). There is a need for the organisation to initial a terms of contract in the business layer between the vendor and the organisation.

TOGAF Phase A – Vision (SOA extensions – Vision Enhancements) derived from the a specific problem (inputs) space and stakeholders’ requirements. Identify an appropriate scope (steps) for the project, what deliverables (outputs) are relevant to the problem.

TOGAF Phase B – Identify your processes and services that support them. What are the terms of service as an artefact? What are the rules? Who can change the terms of service? Added SOA enhancements: Information and information components. What information needs are required for the service to be active (business objects, entities)?

Having a repository

What is the size of your architecture team? What is the maturity of your modelling team? What tools do you use? How level of tool sophistication is required? How much process models do you need to track? The challenge lies with instantiating your architecture in a real life situation. Are we just creating artefacts that are rarely involved in actual solutions? How do you ensure your artefacts are reusable?

Using Visio and Archi modelling tools, SharePoint may be sufficient for small teams.

The big one: Ownership of the architecture is the stakeholder and not the implementer.