Strategic Technology Architecture
for
Maine State Government
What does it mean for Maine State IT?
Nancy Armentrout
B. Victor Chakravarty
Strategic Architecture Committee
Charter
• Ad-hoc committee, chartered by the CIO.
Members & Chair appointed by the CIO.
• Set and communicate architectural directions for
critical IT infrastructure and applications.
• Examine emerging issues and develop
architecture road-maps for guiding day-to-day
decisions and new projects.
• Horizon is two bienniums, rolling.
Committee Members
• Core Tech: Greg McNeal, Jon Richard,
Wayne Gallant, Sheldon Bird, Mark
Kemmerle, Mike Pomerleau.
• Agencies: Kevin Jones, Nancy Armentrout
(Chair), David Blocher, Art Henry.
• OCIO: Kathy Record, Victor Chakravarty,
Paul Sandlin.
Why Common Architecture?
• Many existing one-off solutions to support.
• Use our limited resources wisely. Be cost-effective.
• Orderly sunset and support of legacy
products/technologies.
• Guide RFPs and purchases.
• Develop appropriate skills to properly support our
services, technologies, products.
Why Strategic Architecture?
• Facilitate the Governor’s interoperability and
integration initiatives.
• Support agencies and programs as they
proceed to improve service delivery and reduce
costs.
• Provide integration of services, improved
access, and higher availability. These are now
routine expectations of agencies and programs.
Committee Strategy
• Iterative approach
– Urgent need to limit the buffet of technology
options and increase interoperability.
1. First Pass
– Identify mainstream technologies that move us
forward in the direction believed to be correct
– Standardize
2. Second Pass
– More strategic
– More input from the business community
– Refine standards where necessary
The First Pass
• Review 2002 Strategic Plan.
• Start with categories identified in the old plan,
modify and add where applicable.
• For each category describe where we want to be
in four years – using To-Be Roadmaps.
• Identify technologies and products that help us
get there and those that don’t – using Gartner
Brick format
• Put To-Be Roadmaps and associated Bricks out
for vetting.
• Hold focus group sessions to help get feedback
• Update the bricks as standards
• Publish internally. Incorporate in RFPs, etc.
The Second Pass
• Engage the IT Executive Committee.
• Talk to leaders in agencies and programs, to
understand where they are headed with service
delivery, information management, tools,
connectivity, etc.
• Develop the technology directions to support
such plans.
• Refine & finalize the To-Be Roadmaps.
• Refine & finalize the Bricks to support them.
• Publish externally. Link to RFPs, etc.
Committee Outputs to Date
• Intranet Site for Internal Publishing
• General Architectural Principles Guidelines for Every Day Decision-making
• Database Brick
• Newsletter Articles
• Meager feedback so far. Request more!
To-Be Roadmaps & Brick
Categories Identified to Date
1. Single Sign On: Identity & Authentication
Management
2. Web Publishing
3. Database, Reporting & Data Warehousing
4. Client Provisioning
5. Server Infrastructure
6. Applications Architecture
7. Network Services
8. Security
Criteria used to make selections
• Installed base within the State
• Customer Value (ROI) –discussed this criteria
having the most weight
• Supportability
• Sustainability, (or Viability)
• Market Position
• Training Effectiveness
• Scalability
• Alignment w/ the long-term architecture vision
• General excellence (Enterprise-class product)
Today’s Agenda
• Describe the Brick format and the DB
Brick.
• You are the focus group for the DB Brick
(both format and content).
• What is the best way to reach you in the
vetting cycle?
• Introduce the Single Sign On and Web
Publishing drafts (both To-Be Roadmaps &
Bricks).
Brick Format
Brick: Database Management System
Domain: Data Services
Last Updated On: October 5, 2007
Current
1. Baseline Technology (Approved & supported for
current usage.)
1. Oracle 10g
2. MS SQL Server 2005
3. MS Access 2003
3. Retirement Targets (Exit ASAP.)
1. Lotus Approach
2. R:Base
3. FoxPro
4. Paradox
5. Predecessors of the Baseline Technology, no
longer supported by their vendors.
New Development in Two Years
2. Mainstream Targets (Primary candidates for future deployment, subject to further review and
acceptance by the CIO.)
Descendants of the Baseline Technology
4. Tactical Deployment (May be piloted
5. Strategic Direction (Secondary candidates for
during the next two years, by permission of the
CIO, in the absence of defined Mainstream
Targets.)
future deployment, depending on market trends, but
essentially the same technology and revenue model as
the Mainstream Targets.)
None Identified
None Identified
6. Containment Targets (Current usage OK. NO further proliferation. Long-term exit plan. For waiver,
submit request to the CIO, stating the business requirements and potential support models.)
1.
2.
3.
4.
New Development in Five Years
MySQL
DB2
Progress
Predecessors of the Baseline Technology, still supported by their vendors.
7. Emerging Technologies (New technology
and/or revenue model that could potentially disrupt
the Strategic Direction. May undertake R&D
evaluation by permission of the CIO.)
1. Open Source Relational Databases
2. XML Databases
8. Implications, Dependencies & Rationale
1. MRS intends to exit out of DB2 over the next three years. DOL intends to exit out of Progress over the next three to five years.
2. MS Access is approved for prototyping and localized workgroup usage. It’s not approved for business-critical or wide area usage.
3. MySQL may be deployed only by the express approval of the CIO.