evolving architecture “case study: architecture in statistics nz” presented by: rosemary mcgrath...
TRANSCRIPT
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?
Identify a ‘Framework’
Architect
Develop an Architecture
<<include>>
Stakeholder
DocumentRequirements
Define a Vision
<<include>>
BusinessAnalyst
TestAnalyst
Design theSolution
SolutionArchitect
<<include>> <<include>>
<<include>>
Developer
<<include>>
Implement the Solution
Validatethe Solution
<<include>>
<<include>>
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 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 Cycle
http://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.
12
How has our approach changed?
People Process Methods Software
Process
Methods
Software
People
Time
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
Identify a ‘Framework’
Architect
Develop an Architecture
<<include>>
Stakeholder
DocumentRequirements
Define a Vision
<<include>>
BusinessAnalyst
TestAnalyst
Design theSolution
SolutionArchitect
<<include>> <<include>>
<<include>>
Developer
<<include>>
Implement the Solution
Validatethe Solution
<<include>>
<<include>>
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
1.2.
3.
4.5..
Processes external to core IT architecture processes
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
Enterprise Architecture Framework
Documentation
Architecture Governance
Architecture Blueprints
Architecture Communications
Plan
Architecture Documentation
Process
Architecture Blueprint Process
Architecture Framework
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?