State of Colorado IT highlighted in GovExec as example of Smart Lean Government

Blog post
edited by
Matt Tricomi

Xentity staff has been supporting Methodology Development with ACT-IAC on Smart Lean Government – http://smartleangovernment.com . A recent GovExec article has come out highlighting Smart Lean Government as well as the State of Colorado. 

Opening

In a data-driven world, agencies can’t afford to go it along any more. When Hurricane Katrina struck the Gulf Coast in 2005, the response and recovery were considered a disaster for government. There was no clear chain of command.

Our efforts at Smart Lean Government is in trying to introduce cross-government management and design of services across communities, be life event-based, and find ways to integrate services in design and implementation.

You can see the print magazine version in PDF here or the web version.

Here specifically is the part on the State of Colorado Office of Information Technology point of view

Treating Citizens Like Customers in Colorado

As a private sector technology executive, Kristin Russell [note: recently outgoing CIO] watched companies become adept at tracking customers from one division to the next and learning everything they could about them along the way. 

When a warranty expired, a product was recalled or a superior product came out, they knew just who to contact. And they knew the best way to contact them. 

When Russell became Colorado’s chief information officer, she saw something different. State agencies weren’t competing with anyone, so they had little incentive to offer great customer service. 

This wasn’t just bad for citizens. It was costly for government too. One agency spent $4 million annually on postage. If citizens could opt for email-only contacts statewide, that figure could be reduced significantly, Russell says. 

Russell and Colorado’s Chief Technology Officer Sherri Hammons started planning for a governmentwide customer relations management system that could recognize citizens from one agency to the next, save their addresses and personal information, and alert them to services they might qualify for. 

An early version, called PEAK, offers a unified portal for medical, welfare and child support services and links to the state’s new online health insurance marketplace. Russell hopes to expand the PEAK concept across Colorado’s 22 agencies so citizens can interact with government once and be done. 

****

Xentity is excited to be supported both the SLG initiative and a service provider for the OIT in support of moving to IT in the state to a customer oriented set of services as part of the Xentity’s recent award of IT IDIQ from State of Colorado.

How mature is your service architecture

Blog post
edited by
Wiki Admin

Figuring out what architecture style you are ready to move to is very important before jumping around great ideas vendors are selling you. Yes, the ideas are likely very good and the vendors may be right that you NEED those features, forms, concepts, etc. But, the question is your organization ready enough to adopt these service models.

Moving into service models require a greater level of maturity as you add more responsibility. An internal standalone system or even enterprise integrated systems are used by trained users 9-5. You are responsible to the service level to employees, and if it isnt up, then management would reset employee expectations during those periods. This is much different than web applications calling those systems 24/7 to untrained users with access from anywhere. More so, if the services supporting the web application could be called by other ecosystems, people could now harvest and build many other interfaces for their own community. Now your are responsible to a service level of users you do not manage – which means re-setting expectations during downtime or slow periods is very, very difficult.

By having a view of your readiness to maturity into the service arena, this can let you know how much you need to invest in business, governance, methods, applications, architecture, information and infrastructure to get there.

The Service Integration Maturity Model (SIMM) is a standardized model for organizations to guide their SOA transformation journey. By having a standard maturity model, it becomes possible for the organizations or industry to benchmark their SOA levels, to have a roadmap for transformation to assist their planning and for vendors to offer services and software against these benchmarks. (Wikipedia)

IBM and The Open Group have adopted and expanded upon these concepts. 

IBM Summary

Silo (data integration)

Level One: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change.

Integrated (application integration)

Level Two: The organization moves toward some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches it uses are tailored to use legacy systems and attempt to dissect and re-factor through data integration.

Componentized (functional integration)

Level Three: At this level, the organization componentizes and modularizes major or critical parts of its application portfolio. It uses legacy transformation and renovation methods to re-factor legacy J2EE or .NET-based systems with clear component boundaries and scope, exposing functionality in a more modular fashion. The integration between components is through their interfaces and the contracts between them.

Simple services (process integration)

Level Four: The organization embarks on the early phases of SOA by defining and exposing services for consumption internally or externally for business partners — not quite on a large scale — but it acts as a service provider, nonetheless.

Composite services (supply-chain integration)

Level Five: Now the organization extends its influence into the value chain and into the service eco-system. Services form a contract among suppliers, consumers, and brokers who can build their own eco-system for on-demand interaction.

Virtualized services ( virtual infrastructure)

Level Six: The organization now creates a virtualized infrastructure to run applications. It achieves this level after decoupling the application, its servcies, components, and flows. Now the infrastructure is more finely tuned, and the notions of the grid and the grid service render it more agile. It externalizes its monitoring, management, and events (common event infrastructure).

Dynamically reconfigurable services (eco-system integration)

Level Seven: The organization now has a dynamically re-configurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring.

Open Group Summary

Each level has a detailed set of characteristics and criteria for assessment.

The Open Group has a nice matrix that shows not only the 7 levels, but how it impacts business, governance, methods, applications, architecture, information and infrastructure.

 

Xentity holding Methodology Development review for ACT-IAC, Smart Lean Government

Blog post
edited by
Wiki Admin

Xentity, Methodology Development example (2002-2008 How TAA grew to MBT grew to OMB FSAM)

Over 6 years, it took several iterations of method, applying to projects scaling up method scope, application on programs/segments, lots of info sharing, and then promotion to base of FSAM. This is not to direct the Content of the ACT-IAC, Smart Lean Government (SLG) efforts, but how the method got developed, training material built out and trainer, how the team went out information sharing, promoting, and then helping apply to support true business transformation and modernization blueprints.

Summary of Objectives:
– Covered how Xentity and partners supported the Dept of the Interior iterate/develop the “Methodology for Business Transformation” showing some sample deliverables, templates, and visuals
– Discuss how we iterated from Bureau TAA (02-03) to DOI MBT (04-06) to OMB FSAM (07-08) through maturing from bureau, to agency, to federal through not only iterative method development, but through applying in iteration. First a few blueprints at bureau, then four at agency cutting across different driven blueprints (legal, organization development, target architecture, and shared services), then improving the method, and doing more blueprints, then doing more communications and training, and finally, promotion to OMB through collaborative integration with other methods.
– Cover lessons learned, critical success factors (i.e. framework agnostic, mapping to frameworks, culture understood, tested in 3 cycles of blueprints, breaking into services, first attempted foray into doing as NGO in 2006)
– Pitfalls (i.e. overselling, under training, lacking certification, didn’t emphasize earlier phases, limited bureau accountability, perception and politics, moving to FSAM – losing key aspects, calling it method instead of approach, perceived waterfall and not presented situational, training/maintenance budget limits)
– Cover things we would do now differently (i.e. wiki, more examples, more new Media communications)

Related Xentity links: