Examining Different Architectural Models to get Best Fit with your Organisation CASE STUDY:

1
Examining Different Architectural Models to get
BestFit with your OrganisationCASE STUDY
Evolving Architecture in Statistics NZ

• Presented by Rosemary McGrath
• Enterprise Architecture Manager
• Statistics New Zealand

2
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

3
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

4
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/200
  6/03/27/423300.aspx

5
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
  frameworks
• http//msdn.microsoft.com/en-us/library/bb466232.a
  spx
• 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

6
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)

7
A History of Architecture at Statistics NZ
2006
2005
2009
2008
2007
2004

• Acknowledgement Gartner Hype Cycle
• http//www.gartner.com

8
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.

9
Remember!!
10
(No Transcript)
11
Early Problem 1
_at__at_!! _at_!
Architecture, SOA, Web services, Reuse
12
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

13
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
People
Process
Methods
Software
Process
Methods
Software
Time
15
What has helped us? The Domain Model
16
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

17
What has helped us? The War room
18
Conclusions

• Everything Evolves
• There is a light at the end of the tunnel

Were doing what we can to ensure its not a
train!!
19
What are we doing next?
20
The Relevant Views/Perspectives for our
Architecture Framework
21
Starting to complete the jigsaw
22
Re-Invigorating the Architecture Service Model
1.
2.
3.
4.
5..
23
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.

24
Questions?