Back in May, HHS named its chief enterprise architect. The position is a growing trend among federal and state agencies. Utah is currently in the process of trying to hire the same position. I mention that because Melissa Chapman, the CIO of HHS was in Park City for the Western CIO Summit. Yesterday, she asked our panel, "Aren't we often creating more elaborate silos when we design enterprise projects (at the state level for example) and do not fully consider what everyone else in government is doing (which is almost impossible due to complexity)?" Her point is certainly a good one, although standards based design that focuses on open architectures like XML to deliver services can certainly help provide a solution to that dilemma along with adequate security and trust models.
What Melissa is doing with the federal government is tremendously important to Utah and all of the states for many reasons including the fact that HHS' financial systems (Medicaid, Medicare, etc.) manage a large share of the federal budget, much of which is passed down to the states. Federal projects like the Federal Health Architecture and Consolidated Health Informatics need to be understood at the state level. Ms. Chapman has an aggressive agenda, as stated in an interview with Washington Technology, "We would hope to see a usable product, maybe not finished, but something that could be used for analysis on how to pursue with technology is six to 12 months."
GAO Executive Guide, "Information Technology: A Framework for Assessing and Improving Enterprise Architecture Management"
Just had an idea: As I see or think of ideas for vertical integration, I think that I may create a database of these opportunities along with actionable items to help make it happen.
More summaries from the summit:
Alan Mather's thoughts on enterprise architecture:
"...before technology, the data we had was our asset. We looked after it - there was one master source for the books of a company, one customer list and so on. When technology came along we quickly created many copies of our data, manipulated them in different ways, allowed the marketing people to talk to the customers one way, the sales people another way, the product people another way. We added products that needed new systems that didn't work the same way as the old systems. We kept the programmes and the data closely coupled and didn't share anything. Before long, the data wasn't the asset, even the systems weren't the asset. If we had an asset, it was probably the few people who had been around long enough to understand what had happened, what we had originally and how the systems interacted - every company has a few of those people. We need to go back to the data being the asset."
I finally found time to digest Alan's thoughts this afternoon. He's right. And those people who know how to absorb, analyze and present the data are a valuable commodity as he suggests - but can also conceivably manipulate the data (in both good and bad ways), particularly without an additional control layer.