“Creating a New Business Model for NZ's National Statistical by hcj

VIEWS: 4 PAGES: 30

									   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?

                                                                         Solution      Identify a
                       Define a                           Design the     Architect   ‘Framework’
                        Vision                             Solution

                                                                                                       Architect

                                      <<include>>                      <<include>>
                                                                                     <<include>>
                 <<include>>                   <<include>> <<include>>
Stakeholder

                                             Validate           Implement
                                           the Solution        the Solution

                             <<include>>

               Document                                                                 Develop an
                                                    <<include>>
              Requirements                                                              Architecture




                                                                        Developer
                                   Test
   Business                        Analyst
   Analyst
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               Methods
          Process People         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

                                                                         Solution      Identify a
                       Define a                           Design the     Architect   ‘Framework’
                        Vision                             Solution

                                                                                                       Architect

                                      <<include>>                      <<include>>
                                                                                     <<include>>
                 <<include>>                   <<include>> <<include>>
Stakeholder

                                             Validate           Implement
                                           the Solution        the Solution

                             <<include>>

               Document                                                                 Develop an
                                                    <<include>>
              Requirements                                                              Architecture




                                                                        Developer
                                   Test
   Business                        Analyst
   Analyst
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.
                                           Architecture   Enterprise Architecture   2.
                                                                  Framework          Architecture
                   Change/ Release         Compliance          Documentation        Documentation
                     Management
                                             Process                                   Process
                                                               Architecture
                                                               Governance
Processes
external to core                                                                    3.
                                                                                         Architecture
IT architecture                                                 Architecture
processes                                                        Blueprints
                                                                                           Blueprint
                                                                                           Process
                                                               Architecture
                       Business                              Communications
                                     5.. Architecture               Plan            4.
                       Strategic                                                     Architecture
                       Elements            Framework                                Communication
                                             Process                                  Process
                     IT Strategic
                       Elements


                     Architecture
                   Review 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?

								
To top