Jason Fried: Why work doesn't happen at work | Video on TED.com

An interesting talk that seems counterintuitive to how most organisations think...

Jason Fried: Why work doesn't happen at work Video on TED.com

Enterprise Architecture Development - Preface

Following on from my last post (many, many months ago...), a corollary to ‘What is Enterprise Architecture?’ is often followed by ‘I’ll have one of those...’ and in the case of clients ‘so how long will it take and how much will it cost...’. The more important question in my opinion is ‘What am I getting? and ‘Is it what I really want?’.

A number of frameworks and methods exist for achieving this, depending on the provider. Every consulting organisation has it’s own ‘proprietary’ framework for enterprise architecture, referenced to an open model such as TOGAF. All unique, yet so, so similar to each other. The deliverables and processes may have different names but fundamentally they strive to achieve the same objectives.

These key objectives of developing an Enterprise Architecture are related to the need for blueprints.

Of course, to truly be usable across the enterprise, these blueprints need to span across various aspects of the enterprise. In most architecture framework, four major layers within an architectural model are often described and combine to provide this holistic view.

Business Architecture. The focus of this layer is to describe an organisation in terms of its business context. This is based upon the organisation’s vision, mission and values which in turn drive the strategic objectives and key business drivers. From a contextual perspective, the architecture describes the value chain within the organisation and encompasses the structure and core functions of the organisation. These core functions in turn help derive the core business capabilities required to be serviced by IT systems.

Information Architecture. While the business architecture can be thought of as describing high level business functions and processes, associated with these processes is a flow of information across the organisation. The information architecture describes this flow of information (which may be structured or unstructured and be through electronic systems or hardcopies) along with their usage.  The architecture also describes the consumers and producers of this information both within the organisation and between the organisation and its key stakeholders e.g. customers, suppliers.

Application Architecture. Having described the key capabilities and the information that is transacted through these processes, the next key step is to describe the systems that provide the IT capabilities to fulfil these business processes and flow of information.  The portfolio of software applications in terms of their business functionality, technical structure and integration (relationships between them) is represented within the application architecture.

Technology Architecture. This describes the core infrastructure components and protocols used to support the business and the subsequently, the portfolio of software applications. Additionally, it includes the management and monitoring required to maintain and support the technical environment.

Two other elements that are often implicit are Security and Governance.

Security deals with the management of the information and systems that facilitate the business capabilities. It also provides key enabling functions such as authentication and authorisation to systems and auditing and logging of information.

Governance is an aspect that is sometimes omitted. It’s emphasis is on the management of the processes and systems and the ongoing mechanism to ensure alignment of business and IT.

Based on the objectives to be achieved and the specific business need, the approach and areas of focus may differ. Ideally, an enterprise architecture should be developed top-down ensuring business alignment as each of the layers are progressed. However, it is often the case that certain layers of the model will require a stronger emphasis and level of detail. For example, if the focus is on information management within the organisation, the Information Architecture would be developed in detail with the business architecture layer defined with sufficient detail to facilitate this but not necessarily the same level of detail as the information architecture.

Irrespective of the layers of focus, the general approach to developing an architecture often consists of the same key steps – discussed in further posts...

Enterprise Architecture

I often get asked 'what I do for a living?'.. to which, the response 'Architecture & Strategy' or 'Enterprise Architect' often draws several responses ranging from blank looks, puzzlement and a change of topic... 

In some rare circumstances however, this is followed up with 'so what do you EXACTLY do?'...

While a 'vague' answer may do with colleagues and friends, it's often a completely different story when the question is asked by a client to whom you are selling the service offering...

So.. what is 'Enterprise Architecture'? 

The definition according to MIT is 'Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.'

The Open Group (TOGAF) goes one step further to define why an organisation needs an enterprise architecture:

'The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy.'

While all of this provides a definition or explanation - it still does not tangibly (in my opinion) demonstrate the need or the value of Enterprise Architecture. Particularly when the audience is not architecture or even technology focused, this presents an even greater dilemma.

A good way to explain most ideas is through tangible examples of practical application. Often samples of architecture and its benefits can be utilised to describe the value and outcomes that may be achieved for an organisation through enterprise architecture. However, every business operates slightly differently and the drivers and jargon used within one industry may not necessarily resonate with another.

While searching for this elusive 'easy to understand and communicate' definition, I came across one such popular and widely used example.

The 'Winchester Mystery House' is a well-known Californian mansion that was built under the guidance of Sarah Winchester, the widows of the fun magnate, William Wirt Winchester. 

Some key facts of the house:

• 38 years of construction with 147 builders and 0 architects
• 160 rooms - 40 bedrooms, 6 kitchens, 2 basements, 950 doors
• 65 doors lead into blank walls, 13 staircases were abandoned mid construction and there are 24 skylights in the floors
• No architectural blueprint exists
• Winchester never had a master set of blueprints, but did sketch out individual rooms on paper and even tablecloths

While this seems like a rather interesting fact and a potential tourist attraction in the Californian region, it importantly highlights the need for a plan/blueprint/architectural approach. In essence, an enterprise architecture provides for an organisation what Winchester didn't have - a master set of blueprints.

In this case, the master set of blueprints links the key business goals and strategy to enablers, in the form of an organisational structure or the IT environment (including the applications and systems).

More to follow...