implementing an enterprise & solution architecture
TRANSCRIPT
Implementing an Enterprise & Solution Architecture Capability at
a Health Care Insurer Open Group Conference, Boston | 22 Jul 2014
1
Al Zannini, Director - Architecture & Design, Blue Cross Blue Shield of Rhode Island Dan Hughes, Principal Consultant and Partner, Systems Flow Inc.
Abstract This is a case study of re-launching an Enterprise and Solution Architecture practice at Blue Cross Blue Shield of Rhode Island. It will review a multi-year journey to build capability both upward toward managing from a more enterprise perspective and downward to formalize the practice of designing and implementing solutions in order to streamline the road to production. This transformation took place on the heels of a migration to a new core processing platform and over the course of the enormous architecture challenges presented by Health Care Reform, thus requiring a careful and incremental roll out so as not to impact any regulatory deliverables. The study will highlight the common challenges of building capability while juggling the typical workload of mission critical activities, and share some strategies for being successful.
2
BACKGROUND
3
Blue Cross Blue Shield of RI • Committed to helping
Rhode Islanders meet their healthcare needs
• Licensee of the Blue Cross and Blue Shield Association
4
Our Vision To improve the quality of life of our customers and of the people of Rhode Island by improving their health.
Our Mission To improve members’ health and peace of mind by facilitating their access to affordable, high-quality healthcare.
• Largest Health Care Insurer in RI, founded in 1939 – 600,000+ Members – 9,000+ RI Providers – 1,000+ Employees
Information Technology • Most application development
and support outsourced • Dozens of distinct IT capability
areas within Blue Cross and partner
• $25M annual project budget – 40 enterprise scale projects – 100 smaller scoped maintenance requests
5 ★Additional 50+ read-only for run-out purposes
State of the Enterprise
6
• IT was 99% outsourced to partner (mostly mainframe)
• Small team of IT staff for oversight (<10)
• Completed 5 Year, $200M program to replace core claims processing system
• Increased internal IT capabilities • Expanded to ½ dozen strategic vendors,
including outsourcing partner
2012
20
06
State of Architecture
7
• No enterprise view of application architecture • Governance checkmark vs. active driving of
solution portfolio • Architecture efforts not focused on most
significant projects • Infrastructure-oriented architecture
deliverables
+ Health Care Reform on the way!
WHAT DID WE DO?
8
Our Architecture Transformation
9
Created application overview
Launched architecture governance process Identified architecturally significant projects
Standardized solution architecture process
Built internal architecture capability
1 2
5
3
4
10
Application Overview
11
• Grouped applications by broad functional area • Sub grouped into external facing, core, and
interchange • Application name (and vendor) • Application function
Application Overview
12
• Grouped applications by broad functional area • Sub grouped into external facing, core, and
interchange • Application name (and vendor) • Application function
Application Overview
13
Design approval authority for all Enterprise level initiatives
• Provides direction & governance
• Approves standard and designs
• Authorizes exceptions • Consolidates IT subject
matter experts into 1 room!
Go | No-Go Checkpoints q Inception
§ Bring Business Case or Discovery Document
§ Assess if project can benefit from early EA
§ Approve proceed to scoping q Scoping
§ Bring Solution Scoping Presentation (Conceptual Architecture)
§ Approve proceed to estimation
q Logical Design § Bring Solution Architecture
Document (Logical Design) § Approve proceed to detailed
design
q Detailed Design § Bring detailed design documents § Approve proceed with
implementation
Architecture Governance Enterprise Design Review Committee
Identified Architecturally Significant Projects • Implemented “order of magnitude” significance
model • Applied during planning/budgeting and ongoing • Used for resource planning
14
Boolean significance rubrics
Weighted rating
Standardize Architecture Process • Adopted Investigative Architecture™, a
solution architecture method from Systems Flow
• Built capability through training, mentoring, and pair project work
• Run weekly ongoing peer review sessions – Discuss technique and deliverables – Create visibility across projects
15
Built Capability • Hired with new role in mind
• Augmented training with partnering and mentor reviews
• Modified employee goals to coincide with successful delivery
• Evaluating Open Group Architecture Certification (Open CA)
16
About Investigative Architecture™
17
Investigative Architecture™ • Defines process for solution design
– Very diagram (mostly UML) and deliverable focused
– Lightweight “right-sized” documents – Toolkit includes templates, samples,
guidance, and training
• Recognized by the Open Group • Aligns with many architecture and
project processes • Builds iteratively to maximize
architecture value and supporting investment decisions
18
Business Context
• Understand the target solution in terms of the users and capabilities they will require.
• A good, quick way to confirm scope.
Design Options Analysis
20
Vet multiple valid design options if: - There are divergent, but
seemingly valid solutions - An invalid solution needs to be
factually disproved
21
Solution Scoping
Produce solution scoping to: 1. Rapidly converge on a conceptual level
solution 2. Validate it meets the business need 3. Provide enough scope for the technical
teams to estimate
22
Logical Architecture
• Define a roadmap for detailed design
• Gain buy in from all impacted technical teams
• Ensure solution can be supported
Implement Technical Lead Role • PMO was clamoring for more technical support
through the lifecycle • Architecture is critical, but a solution brings
no business value at all until it is in production. • This is a very dangerous role from a scope
perspective. Need to: – “Do enough” to guide successful delivery. – Not do so much that other EA & SA work is
compromised.
23
Technical Lead Responsibilities Throughout Life of Project ü Brief Director of EA on current status of
project, design, and implementation, including any concerns.
ü Participate in ongoing project status meetings
ü Ensure business and project stakeholders are clear on Solution Architecture level architecture design as described in Solution Scoping and Solution Architecture document.
ü Update Solution Architecture documents as required as new information is learned
ü Facilitate technical decisions to conclusion.
ü Represent project in EDRC reviews.
24
✎ Implementation Diagram. Confirms high level project activities required to implement solution.
During Detailed Design ü Ensure detailed designs align with
solution architecture as described in solution scoping and solution architecture document.
ü Ensure design is adequately and appropriately documented.
ü Facilitate design sessions for cross-team aspects of integrated components.
ü Participate in all final detailed design reviews.
ü Review and approve all detailed designs on behalf of Director of EA.
ü Participate in any cross-team design meetings
ü Influence detailed designs toward best practices
After Detailed Design ü Act as technical focal point for any
changes to designs a result of information or change requests post-design.
ü Provide technical leadership and oversight for technical issues. Ensure appropriate resources are engaged.
✎ Options Analysis. Drive fact-based analysis of design decisions. Final decisions to be documented in Solution Architecture document.
✎ Design Deliverable Catalog. Spreadsheet to ensure design document coverage across all components.
✎ “As Needed” Design Clarifications. EA may product additional views to confirm or clarify design details.
These are in addition to Solution Architecture delivery activities & deliverables.
Deliv
erable
s
WRAP UP
25
Where are we now?
26
• Understand high level application portfolio • Starting to build reference architecture for a few
priority areas • Architect and projects know what to expect • Proactively facilitating solutions • Able to communicate anecdotal success to
management • Still struggling to establish better metrics
Proposed Roadmap
27
Enterprise Direction
Project Support
Solution Architecture
Technical Leadership
Enterprise Architecture
Proposed Roadmap
28
Enterprise Direction
Project Support
Solution Architecture
Technical Leadership
Enterprise Architecture
Proposed Roadmap
29
Enterprise Direction
Project Support
Solution Architecture
Technical Leadership
Enterprise Architecture
1. Train 2. Mentor 3. Incent 4. Hire
Lessons Learned • PM’s follow a plan to a T: make sure their plan
includes you
• The architects you have may not be the architects you need
• Anticipate other areas trying to push more responsibilities on your plate
• Be prepared to manage expectations
• Repetition creates comfort: delivery consistently
30
Tips • Supporting projects earns EA credibility
• A architecture process partner can help fast track deployment/implementation.
• For determining architecture significance, anything is better than nothing
• Start simple. Succeed. Rinse and repeat.
• Market up, down, and sideways.
• Partner with your PMO.
31
Authors
33
Al Zannini has over 30 years of wide-ranging technology experience in the health-insurance, retail, and financial industries. Al has held IT application and project management positions at several large scale/fortune 100 companies including CVS Pharmacy, MetLife, and Fidelity Investments. He is currently Director of Architecture & Design at Blue Cross Blue Shield of Rhode Island where he has built a team of architects responsible for the design and integration of the company's internal, hosted and third party application infrastructure, ensuring the most efficient use of available resources. Al has a B.S. in Organizational Management from the University of Rhode Island. Outside of work Al is an avid golfer, skier, and part time musician who has played drums professionally for over 30 years.
Dan Hughes is a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice. He has decades of software engineering experience spanning a broad range of technologies and techniques. Startup to enterprise, he has launched, managed, and executed all aspects of both product and enterprise life cycle, delivering complex, enterprise-scale architectures for clients in the public and private sector, in industries ranging from banking, health care, and insurance to international development. He has guided the launch and participated in ongoing operations of Enterprise Architecture teams at numerous clients in multiple industries and has served on the United Nations Development Programme IT Governance Board as an external member and advisor. He holds a Bachelor of Science in Computer and Systems Engineering from Rensselaer Polytechnic Institute and blogs on architecture topics at http://www.sysflow.com/dhughes. Dan’s non-architecture time is consumed by his family and his obsessions with his lawn, home automation, and genealogy.
References More information on this topic - Systems Flow Architecture Blog sysflow.com Articles on Investigative Architecture sfi.cc/inv Articles on Technical Leadership sfi.cc/delivery More about Systems Flow training sfi.cc/learn
34
About Systems Flow
Systems Flow helps organizations dramatically improve their competitive advantage through the practical, effective application of best practices in enterprise architecture and software development. Investigative Architecture™ is our method that facilitates the rapid assessment and documentation of ‘as-is’ and proposed IT architectures. We developed this Investigative Architecture approach a decade ago in support of our enterprise and solution architecture consulting services.
35
Follow us on twitter (@systemsflow) for information and announcements Read our blog: http://sysflow.com/blog Any questions? Email us at [email protected]
APPENDICIES
36
Architecture vs. Governance
37
Architect EDRC (Governance) • Propose and document standards
and reference architectures • Design solutions that meet
business requirements and timelines, and align with enterprise standards and best practices
• Ensure development of enterprise applications is delivered according to BCBSA, state and federal regulations, BCBSRI standards and industry best practices
• Assist with initial vendor/package evaluations/recommendations
• Provide technical leadership to projects through implementation
• Review projects and provide technology direction
• Commission and approve standards and reference architectures
• Approve Solution Designs • Approve exceptions to IT
standards • Make final decisions regarding IT
capability to deliver emerging technologies
• Review/evaluate request for technology support on initial vendor selections or package review
38
Should Technical Lead Be Doing This? YES
• Completing all of the tasks and activities associated with solution scoping and solution design • Performing all of the “technical lead responsibilities” outlined above • Untangling detailed design issues
NO • Creating project plans • Filling and submitting project forms • Tracking project issues • Running project status meetings • Creating detailed design
documents • Increasing scope to cover non-
technical aspects of project • Developing code, configuring, or
creating data files • Doing data mapping or field/data
gap analysis • Performing functional analysis or
design beyond Use Case identification