Evolving Architecture
“CASE STUDY:
Architecture in Statistics NZ”
Presented by: Rosemary McGrath
Application Architecture Manager
Statistics New Zealand
Agenda
•
•
•
•
•
•
•
•
•
Statistics NZ
Drivers for Change
Where Does Architecture Fit?
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
Statistics New Zealand
• Government agency
• New Zealand's national statistical office
• Leads New Zealand’s Official Statistics
System
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
– Enables continuous improvement through the increased
adoption of standards, improved methodologies and best
practice
• Enhancement of Statistical Effectiveness
– Increased utilisation of administrative data
– Expanded role in leadership of the Official Statistics System
(OSS)
– Increased demand for access to timely and relevant
statistical data
And so, Where Does Architecture Fit?
Design the
Solution
Define a
Vision
Solution
Architect
Identify a
‘Framework’
Architect
<<include>>
Stakeholder
<<include>>
<<include>> <<include>>
<<include>>
Validate
the Solution
<<include>>
Implement
the Solution
<<include>>
Document
Requirements
Business
Analyst
Develop an
Architecture
<<include>>
Test
Analyst
Developer
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 – “A” Definition
•
Architecture is the use of sets of abstractions and models of a environment, problem space
or domain, either physical or logical, with a set of associated views into that domain to
provide:
–
Simplification and management of complexity in all it's forms (structural, procedural
or informational), in particular the management, understanding and integration of the
business and technical domains.
–
Communication and common understanding of the problem space to multiple
stakeholders from widely different environments by the use of multiple domain
specific views of the architectural model.
–
Completeness and relationship analysis of proposed solutions in the problem space or
domain by examining the models and architectures from multiple differing viewpoints
for incompleteness and gaps.
–
Forecasting and predicting future architectures, strategies, structures, patterns,
relationships and technologies in the business and technical space by extrapolation of
present abstractions and models.
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 frameworks
http://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
2006
2005
2009
2008
2007
2004
Acknowledgement – Gartner Hype Cycle
http://www.gartner.com
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.
How has our approach changed?
People
Process People
Methods
Software
Process
Methods
Software
Time
12
Remember!!
Engagement is not saying hello as you
pass on the stairs
Early Problem 1
Architecture, SOA, Web
services, Reuse
##$@@!! %%^&&&
**&^% ##$%#@!
Early Problem 2
• Challenges - Misalignment of strategies, plans, outputs and
outcomes (impacts governance, funding, capability) – What is
the ‘right’ architecture
What has helped us? – The ‘War’ room
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
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
Partial Domain model – Sample
Survey (including weighting)
Weighting is not part of Census as
it surveys the whole population –
Have we identified two different
survey types with different
associations and business rules ?
What are the linkages
Design the
Solution
Define a
Vision
Solution
Architect
Identify a
‘Framework’
Architect
<<include>>
Stakeholder
<<include>>
<<include>> <<include>>
<<include>>
Validate
the Solution
<<include>>
Implement
the Solution
<<include>>
Document
Requirements
Business
Analyst
Develop an
Architecture
<<include>>
Test
Analyst
Developer
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?
Re-Invigorating the Architecture Service
Model
Procurement
Project
Management
1.
Change/ Release
Management
Architecture
Compliance
Process
Enterprise Architecture
Framework
Documentation
2.
Architecture
Documentation
Process
Architecture
Governance
Processes
external to core
IT architecture
processes
3.
Architecture
Blueprints
Business
Strategic
Elements
IT Strategic
Elements
Architecture
Review Process
5.. Architecture
Framework
Process
Architecture
Communications
Plan
4.
Architecture
Blueprint
Process
Architecture
Communication
Process
The Relevant Views/Perspectives for ‘our’
Architecture Framework
Starting to complete the jigsaw
Agile with SCRUM
• Agile with SCRUM
“Scrum is an Agile process that can be used to
manage and control complex software and product
development using iterative, incremental practices.
Scrum has been used from simple projects to
changing the way entire enterprises do their
business. Scrum significantly increases productivity
and reduces time to benefits while facilitating
adaptive, empirical systems development.”
www.controlchaos.com
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?