Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Solution Architecture meets Global Enterprises

No description

Ingo Arnold

on 10 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Solution Architecture meets Global Enterprises

Solution Architecture meets Global Enterprises
Complexity at Novartis has many parents – inside as well as outside of IT
Organizational forces shape IT-Systems - thus IT-Systems mirror the organizations and their multitude of constraining aspects which once created them ...
Novartis‘ organization structure is federated. Divisions have their own IT organizations, where GIS provides x-divisional services
System of Forces
Organizational View
Shared infrastructure IT has to balance the different divisions' individual requirements as well as orchestrate a multi-vendor outsourcing situation
Continuously evolving busi-ness models and innovations in the health environment re-quire very flexible & adapta-ble IT solutions – while at the same time cost pressure increases
Corporate IT
IT Dilemma
Pace of change
Change adaption
Scale effects
CFO Wish List
Scale Changes Everything
Focus on functional growth and contribution to business value led to a complexity problem that we have to deal with today
Quality attributes of big information systems (e.g. agility) compete with these systems‘ functional growth
New functionality
New services
New operating models
CEO Wish List
Architecture helps resolve the Dilemma
Architecture enables Quality, Agility and Transparency for Corporate IT
Resolved Dilemma
Architecture's main contribution is towards an IT-System's quality attributes - thus Architecture helps resolve the dilemma
Ingo Arnold, Head Architecture Management, Novartis
Introduction & Bio
Manage Evolution
The solution to Corporate IT dilemma is to manage a «big system’s» evolution
Big-System Evolution
How is an IT-System's evolution adequately and properly governed?
Architecture Disciplines
Planning, governing, and managing multiple IT-Systems continuously
Enterprise &
Analyzing, shaping, evolving a single IT-Systems within the scope of a change initiative
Architecture Disciplines Analogy
Enterprise versus Domain versus Solution Architecture
The City
The Building
What is all out there?
How do different elements relate to each other?
Do we have gaps?
Do we have overlaps?
What is important?
What is the right order to tackle the problem?
How would a change impact this domain (internally)?
How would a change impact other domains (externally)?
Questions being answered
How the system works (its static and dynamic structures)?
How do system components collaborate & work together?
How is the system internally connected?
How is performance achieved for the system?
How is availability achieved for the system?
How is security achieved for the system?
How is extensibility achieved for the system?
What are the system’s dependencies to other systems?
Questions being answered
EA Life-Cycle
Solution Architecture is considered a black box from the EA Life-Cycle perspective. Focus is on planning.
Black Box
Understand your starting
point and available assets
Model As-Is Architecture
Shape to-be architecture based on reference architecture and results of gap analysis
Model To-Be Architecture
Identify, assess, and close gaps
Perform Gap Analysis
Ensure that initiatives start in the
right way, are delivered in the right way and create the right things
Initiate, Guide and Govern Solutions
Leverage Best Practices, apply Pattern thinking
Model Reference Architecture
Novartis uses TOGAF as an EA Reference Framework. The notion of domains is used to create architecture-related manageable clusters
As-Is Architectures are created and evolved per architecture domain to improve planning, gap-analysis, and strategic alignment across domains and across "big systems".
These components interlink
the Solution with the Enterprise
and Domain Architecture discipline
Gap analysis are performed based on heat-mapping and similar techniques and based on Novartis' cross-divisional architecture repository.
Roadmaps are derived from Target (to-be) Architectures. Roadmaps underpin project portfolio planning and support the alignment of change initiatives over time.
Architecture Patterns are only one of many means and techniques to govern along agreed paths. Other such means include project management frameworks, IT-Standards Management, Architecture Boards, etc.
Solution Architecture Practice
The Architecture Handbook is the name of Novartis' solution architecture development method & description standard.

It is comprised of ...
a process description document
an architecture description template
many complementary documents (e.g. checklists, guidelines, models)

The Architecture Handbook is an integral part of Novartis‘ standard project management methodology even though it can be used also outside of it.

It is based on solution architecture best practices and includes a view model which spans core views and cross-cutting perspectives:
Application Architecture
Data Architecture
Technology Architecture
Security Perspective
Availability Perspective
Performance Perspective
Extensibility Perspective

The method does not replace a highly skilled solution architect
The Architecture development process is iterative and agile

The Architecture Handbook underpins a solution’s whole life cycle

The Architecture Handbook does not replace an IT Architect

The Architecture Handbook is THE reference for architecture related information

The Architecture Handbook supports all types of IT engagements

The Architecture Handbook systematically includes the solution’s context
This means that all chapters are revisited over and over again while evolving the solution architecture steadily rather than 100% completing one chapter after the other in a sequential manner
As a consequence it must be used to support the creation as well as all operational changes to the solution in order to always reflect this solution’s architecture.
The Architecture Handbook does by no means replace a well-educated IT Architect.
Rather think of it as a tool-box that makes the IT Architect’s work more standardized, and highly efficient.
Thereby it provides crucial information for a broad range of stakeholder groups beyond just the IT Architects (e.g. Project Manager, Project Quality Manager, Business Analyst, Requirements Engineer, Service Manager).
It is a clear misperception that proper architecture work and documentation only needs to be performed in the context of custom application development engagements!
Examples are (e.g. package customization, infrastructure service, application integration)
This means that any work that is performed by the IT Architect takes into account the broader business-, services-, information-, application-, and technology-landscapes.
Solution Architecture Practice
Process spans multiple phases and disciplines, is iterative, and incremental
Any entry point into view model and process is possible
View Model is holistic, interlinked, and takes EA into account
Complementary material includes check-lists, training material, show cases and reference AHs
Architecture Handbook Sample
Define Enterprise Architecture Context
Understand envisioned solution within broader Enterprise Architecture context
Refine Principles & Requirements
UC Overview Diagram provides an overview of functional scope and Actors of a given system
Identified UCs are further described in an appropriate table
UC Details help conduct educated discussions with respective Stakeholder groups
Non-Functional requirements capture quality attributes a system needs to fulfill.
Elaborate System Context
Elaborate Application Architecture
Elaborate Data Architecture
Elaborate Technology Architecture
Lessons Learned
AH was used as reference to request solid architecture description from ISV
Reference for vendor’s architecture description
Used as a basis for light-weight architecture descriptions
Black-box Architecture versus white-box Architecture
Several groups already went through AH-trainings. Further AH-trainings were targeting specific groups (QMs, PMs)
Educational training sessions for Solution Architects
HR role definitions are utilizing the AH
Basis for «Solution Architect» role definition
Architecture styles, patterns and other re-usable assets utilized AH’s description approach, its models and notations
Architecture styles and patterns
Thank You! Questions?
Full transcript