Examining Different Architectural Models to get Best

Fit with your Organisation

CASE STUDY: “Evolving Architecture in Statistics NZ”

Presented by: Rosemary McGrath Enterprise Architecture Manager

Statistics New Zealand

Agenda

• Drivers for Change• Architecture ‘A’ Definition• Architecture – the ‘tools’ of the trade• A History of Architecture at Statistics NZ• Conclusions - Everything Evolves• What is Shaping Where we Evolve to Next?• Questions

Drivers for Change• Fiscal Sustainability

– Reduce the risk, time and cost of new statistical developments– Maintain or reduce Total Cost of Ownership (TCO)

• Increased Operational Efficiency– Strengthen the application of common classifications and

standards across subject matter areas– Enable continuous improvement through the increased

adoption of standards, improved methodologies and best practice

• Enhancement of Statistical Effectiveness– Increase utilisation of administrative data– Expand Statistics NZs role in leadership of the Official

Statistics System (OSS)– Enable increased demand for access to timely and relevant

statistical data to be met

Architecture – “A” Defintion

• An often used/abused term• ANSI/IEEE Std 1471-2000 is: "the fundamental

organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

• This is a definition I like – and reflects the way I like to look at ‘what architecture is’

• “Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting.”

http://blogs.technet.com/michael_platt/archive/2006/03/27/423300.aspx

Architecture – The tools of the trade• Architectural Frameworks

– There are quite a few of them – Zachman, TOGAF, FEAF are probably the most well known

– For one perspective on an assessment across the frameworkshttp://msdn.microsoft.com/en-us/library/bb466232.aspx

• Architectural Principles– Each framework has a set of principles– The are very similar– They are not contentious

• Architectural Models– Domain models – Static.– BPMN – Dynamic.– Enterprise models - Big picture– Deployment – Infrastructure/support– Models for technical audience may include Class, Component, ERD

etc – all UML based

Architecture – The tools of the trade – a learned view

• Guidelines– Help people– Clarify understanding– Support implementation

• Direction– Options are key– Feedback

• Roadmap– Let everyone understand– Have clear milestones and deliverables– Be attainable (believed to be attainable)

A History of Architecture at Statistics NZ

Acknowledgement – Gartner Hype Cyclehttp://www.gartner.com

2004

2005

2006

20072008

2009

Some ‘hard’ lessons learned• Having artefacts does not equate to having an architecture. (wide

criticism)• Do not take an extremely structured systematic top-down approach

to establishing an EA. “This type of approach works well when applied to complex but fixed domains, such as building or aircraft construction, but is completely inappropriate when applied to emergent (dynamic) domains such as economies or enterprises.” (Gartner)

• It is OK to have gaps• Accept that there are various levels of acceptance of change (any

change) across the organisation, find those that will partner with you• Find some champions, champion architecture, market (not a

common skill)• Always present options – everyone wants a choice• Architecture is a verb not a noun.

Remember!!

Engagement is not saying hello as you pass on the stairs

Early Problem 1

Architecture, SOA, Web services, Reuse

##$@@!! %%^&&& **&^% ##$%#@!

What has helped us? – The generic Business Process Model

• To define our business processes, we– identified the enterprise wide business processes– abstracted at the business level, NOT the data level or

‘system’ level, and– Stayed at the common level – generally activity, not task– used commonly understood terms to be inclusive

Early Problem 2• Challenges - Misalignment of strategies, plans, outputs and outcomes

(impacts governance, funding, capability) – What is the ‘right’ architecture

14

How has our approach changed?

People Process Methods Software

Process

Methods

Software

People

Time

What has helped us? – The Domain Model

What is a Domain model ?

• Conceptual model of a system which describes the various real world entities involved in that system and their relationships

• Communication tool to validate and verify the understanding of the business domain between various groups. (Technical and non-technical)

• Structural view of the system, complemented by the dynamic (process) views in Use Case models/ User stories

• Domain models (partial) are an important decomposition tool, view the system in many contexts using entities and relationships

• Domain model should apply to the industry – Common Taxonomy

What has helped us? – The ‘War’ room

Conclusions

Everything Evolves

There is a light at the end of the tunnel

We’re doing what we can to ensure it’s not a train!!

What are we doing next?

The Relevant Views/Perspectives for ‘our’ Architecture Framework

Starting to complete the jigsaw

Re-Invigorating the Architecture Service Model

1. 2.

3.

4.5..

Procurement

Project Management

Change/ Release Management

Procurement

Project Management

Change/ Release Management

Architecture Compliance

Process

Business Strategic Elements

IT Strategic Elements

Architecture Review Process

Business Strategic Elements

IT Strategic Elements

Architecture Review Process

Enterprise Architecture Framework

Documentation

Architecture Governance

Architecture Blueprints

Architecture Communications

Plan

Statistics NZ Enterprise Architecture Framework

Documentation

Architecture Governance

Architecture Blueprints

Architecture Communications

Plan

Architecture Documentation

Process

Architecture Blueprint Process

Architecture Framework

Process

Architecture Communication

Process

Agile with SCRUM• What we have noticed so far– Scrum is an implementation of agile

methods and practices– ‘Agile Architecture’, ‘just enough

architecture - allowing for the big, long-term picture as well as the fluid nature of implementation, within 2 week sprints

– Makeup of the teams is important, cross functional and relevant to the current priorities

– There is a shift to architecture becoming a stakeholder instead of a 'prescriber' allowing the focus to change from technology or techniques to working iteratively and incrementally within project teams.

Questions?