About

Jadira is the home for Sousan and Chris Pheby's open source projects. These are reusable open source Java modules that provide first class solutions using the most effective current JEE technologies.

Search
Tag Cloud
...
Login
Thursday
Jan052012

Help! There is No Architecture

I have been thinking about what the steps are that you go through when confronted by - altogether, in whole or part - the absence of architecture in the context of an IT organisation. I've tried to capture a putative approach that is - by necessity - focused firstly on bringing some definition to the technology architecture.

In practice the steps you must take are fairly straightforward:

  • Establish Baseline (As-is) Architecture Find out what is there; take stock and begin to understand what can be used - what is good and what less so.
  • Select Initial Architecture Tooling The purpose of this activity is to have a tool. Its best to defer selection of specialised tools until later - focus on selecting tooling that supports the initial need - typically diagramming backed by some kind of model. For example, I often recommend SparxSystems Enterprise Architect as being a suitable option at this time.
  • Select Suitable Architecture Products At the outset you need to determine what artifacts you are going to produce as part of the architecture. You can find some pointers here. The remaining steps decompose some of the initial areas of architecture products you will want to establish in a typical IT organisation.
  • Select Products that Represent Technical Assets Determine what artifacts you will produce to describe existing technical assets. The broad classifications of these products will be the subject of a future article.
  • Establish A Document Repository You want to get architecture documents under change control with a history of whole made changes and why as early as possible. My default suggestion is to use Subversion in the first case - effective and free.
  • Evaluate and Select An Architecture Framework You can use frameworks selectively, but its useful to take advantage of the collateral that already exists
  • Perform Technology Forecasting Your initial thoughts will be rough around the edges - but you must begin to consider where you want to be.
  • Select Products that Represent Standards Profiles This begins the process of establishing the architecture as an asset that supports its role to facilitate future work.

I'll be looking subsequently at how the architecture inception gives way to an iterative maintenance process - something that is often referred to as architecture vitality.

Thursday
Jan052012

Enterprise Architecture Functions

I have been trying to put together an illustration of the key functions within an enterprise architecture organisation. The basis for the image comes from a forum post describing EA Core Functions.

The grid organises EA into eight components based around the intersection of six themes. The horizontal axis covers activities - planning, facilitation and governance. The vertical covers intents - strategic contribution, measurement and influencing. At the intersection of each activity and intent a core function is described, with the exception of facilitate measurement (this omission should be self-explanatory).

Friday
Dec302011

Calendar Systems

Recently I read the third edition of the excellent Calendrical Calculations. This book is fascinating even if you are not a programmer.

As I was reading, I was amazed at just how many distinct calendar systems we have; the Gregorian calendar now something that generally we take for granted.

 Calendars are highly topical as we reach the end of the year. Of course, in the coming year the Mayan calendar will finally come to an end.

Friday
Dec302011

Enterprise and Solution Architecture - A Pragmatic View

In the previous discussion I introduced the concept of architecture fulfilling a key governance role within the organisation, fulfilling a mediation between the supply and demand relationships. The diagram below is my attempt to communicate about the relationships between these various functions and how architecture contributes to not only technical conformance, but also addressing the alignment of IT with the direction of the organisation it serves.

If you are looking for rigorous meta-model describing detailed causation relationships and semantic relationships between activities and artifacts, don’t look here. Instead, I suggest you start with an established model such as Nick Malick’s Enterprise Business Motivation Model (EBMM) or the Zachmann Framework. The purpose of this model is communication – it provides a pragmatic description of how architecture contributes to facilitation, quality management and alignment.

The “Demand” Function is depicted by the package shown at the top of the diagram. Demand is captured and codified by Business Strategies and Business Initiatives. Strategies describe what the business wants to do in order to create value, and how it will measure and achieve it. The ways in which businesses capture strategy differ from one firm to another, but can include business plans, missions, the Balanced Scorecard, Strategy Maps, the Performance Prism and many other techniques. Strategy sets the context for change. Initiatives are framed by strategy and describe specific changes that are to be executed within the business in favour of the strategies. Initiatives are commonly expressed via a business case, and managed through to delivery as part of a project or programme. Elaboration of initiatives typically begins expressed as a series of desired changes; eventually these are expressed as requirements.

The “Supply” Function aims to fulfil demand in a manner that is traceable back to business need. The architecture discipline that operates in this area is the well-known Solution Architect role. A Solution Architect fulfils a multi-disciplinary role that brings together the various enterprise architecture disciplines in a pragmatic manner. Working in this area you find Technical Design and Integration specialists. The output of Solution Architecture is working solutions. This area is also the domain of Project Management, and typically responsibility for delivery lies between both the technical and management role. A key technique here is the use of benefits management to ensure traceability from business case to delivery, and portfolio management to regulate the continuous alignments of projects. A variety of established practices in these areas help – including PRINCE2: 2009, ITILv3 and Cranfield University’s Benefits Management Framework.

Mediating between Supply and Demand is the “Governance” Function. This is where enterprise architecture resides, together with the variety of programme and portfolio management disciplines. These functions support the responsible executives in facilitating the delivery of value from change. Enterprise Architecture is typically described in a layered view that borrows from the classic representation of Enterprise Architecture as Business, Information, Application and Technology Architecture.

Business Architecture is concerned with the alignment of business and its dynamic capabilities (principally in most organisations specifically the alignment of business and IT). It achieves this by forming a number of holistic views that enable scenario planning, impact assessment and decision making to be achieved. These views include the business processes, the organisation structure, the application portfolio and the capabilities view of the organisation.

Maintained in step with the business architecture, the Information Architecture addresses the entities of the business, their structure, meaning and canonical forms. Information Architecture also considers the disposition and placement of data, its rules and structure and constraints placed on it. It is concerned with the elaboration of a ubiquitous language that can be shared between all stakeholders, including business and architecture.

The Technology Architecture steps from the domain of What to How. It is concerned with elaboration of the organisation strategy into a set of reference architectures, patterns and guidelines. These are supported by development standards, the service catalogue underpinning capability reuse and a base architecture model that provides a conceptual reference view for the organisation’s architecture fulfilment.

All of these artifacts frame and facilitate the work of the Solutions Architect. The interaction between disciplines is supported by Vitality and Governance processes that not only ensure conformance, but also continued development of the Architecture.

 

Friday
Dec302011

IT's Supply, Demand and Governance: EA within Governance

Recently, many CIOs have begun to orientate theirs organisation around a bisected model where the organisation is structured into a demand organisation and a supply organisation. This split generally considered to be evidence of the maturity of the IT organisation (see CHEN, Daniel Q. et al., 2010, p.262). For example, Systems Development (together with the technical infrastructure) is typically positioned as a part of the ‘Supply’ function within the organisation. This is contrasted by the business users, requirements analysis and strategy falling within the ‘Demand’ side.

CIOs are also finding that for this model to succeed, it is often necessary to define a governance function that is independent of either demand governance or supply governance. This arises from the understanding that governance is not only an enforcement activity, but represents a mediation between supply and demand and has a facilitation role. On the demand side, governance is tasked with ensuring the organisation is “doing the right things” whilst on the supply side, governance priorities lie with “doing things right” (GERRARD, Michael, 2010, p.2).

Governance takes many forms, and in the project and delivery lifecycle is already well catered for by established practices such as benefits, programme and portfolio management and in information technology operations management (for example, today organisations are using Benefits and Portfolio Management, PRINCE2:2009 and ITILv3 to good effect in these areas). Central to these discrete governance functions is the overriding mission of better aligning IT with the strategic objectives of the business (SEROTER, Richard, 2011) and improving communication between all stakeholders.

Enterprise Architecture falls within the Governance function, but it is strongly oriented as a facilitation activity. It is a long term undertaking squarely focused on business and IT alignment (SCHMIDT, C and Buxmann, P, 2011). For example, organisations demand measurable requirements with traceable benefits (ENGELSMAN, W et al., 2011). However, before we can affect such changes in systems we need to understand the affected existing processes, resources and functions. We can achieve this by documenting them using an easily understood, standardized, and ubiquitous language. Achieving that documentation and governinig its application is the responsibility of architecture.

 

CHEN, Daniel Q., David S. PRESTON, and Weidong XIA. 2010. Antecedents and Effects of CIO Supply-Side and Demand-Side Leadership: A Staged Maturity Mode. Journal of Management Information Systems. 27(1), pp.231-271.

ENGELSMAN, W, D QUARTEL, H JONKERS, and M VAN SINDEREN. 2011. Extending enterprise architecture modelling with business goals and requirements. Enterprise Information Systems. 5(1), pp.9-36.

GERRARD, Michael. 2010. IT Governance: Key Initiative Overview. [online]. [Accessed 2 June 2011]. Available from World Wide Web: <http://www.gartner.com/it/initiatives/pdf/KeyInitiativeOverview_ITGovernance.pdf>

SCHMIDT, C and P BUXMANN. 2011. Outcomes and success factors of enterprise IT architecture management: empirical insight from the international financial services industry. European Journal of Information Systems. 20(2), pp.168-185.

SEROTER, Richard. 2011. Out of Necessity, Enterprise Architecture Begins to Align Closer with Business. [online]. [Accessed 30 May 2011]. Available from World Wide Web: <http://www.infoq.com/news/2011/05/gartner-enterprise-architecture>