7 years, 9 months ago

Sequestration Planning May Illuminate Value Engineering via Enterprise Architecture

 The next 5 months portend a spectacle of US Congressional battles to be waged ahead of the pending, mandatory “sequester” – automatic, mandatory federal government spending reductions of about $1 Trillion over 9 years, in non-exempt, discretionary appropriations, set to take effect 1/2/2013. Forward-thinking planners in government IT organizations, in large Programs that depend upon IT, and among the Systems Integration (SI) community are likely to dust off Enterprise Architecture skills for analyzing budget cut implications across their IT investment portfolios, and possible cost savings opportunities to offset them. Leveraging a methodical, EA-guided approach to both assess impacts and adjust spending priorities, while illuminating new areas of savings, is a sure route to mitigating serious risks and delays to delivery of critical citizen services.

Whether you’re dusting off the existing EA artifacts, or need to take a very rapid, optimized route to constructing initial enterprise IT models, the driving principle at this time will be rapid, absolute reduction in complexity with a clear line-of-sight to cost savings. “Complexity” here simply refers to an inefficient or needlessly detailed volume of time and resources applied to deliver IT solutions – time spent re-engineering processes, building redundant interfaces and monitors, installing hardware & software in a piecemeal fashion.

Driving complexity, and therefore introducing cost savings, out of engineered systems is the central tenet of “Value Engineering”  – “the optimization of a system’s outputs by crafting a mix of performance (function) and costs”. Essentially, deliver the same capabilities with better value by driving down the cost to build and/or operate. Section 52.248-1 of the FAR (Federal Acquisition Regulations) describes the “Value Engineering Clause” that is inserted into many large Federal IT contracts – enabling the contractor to propose changes to the system being developed (i.e. a “Value Engineering Change Proposal”, or VECP). If the proposal is accepted, the actual or collateral savings derived by the government (through cost modification to the contract) can be shared with the contractor. It’s a win-win opportunity for the government, system beneficiaries and the contractor community to discover and propose engineering changes that will lower costs, yet still deliver the same or better results.

Many VECPs are submitted for technology assets – i.e. contained systems that may work better when newer, less-costly components are substituted…like missile systems or electronic devices. This may be because the contractor typically is the sole source of knowledge and research concerning how to optimize and build the components, the “value” and function of the asset is very clear (i.e. it’s delivered and explodes on target) and constant innovation is a demand of the environment. VECPs are also submitted for IT systems and programs, though it’s much more difficult to identify and propose the specific cost savings or cost avoidance that might result – since IT systems are frequently dependent upon many external or interfaced elements, vendor products and processes.

An EA-centric review of a program or line-of-business IT investment may quickly yield insight that would lead to specific value engineering opportunities, and therefore reductions in IT costs. For example, a particular set of information may be created, shared and recreated across several systems, using different processes, datastores and technologies. An segmented EA approach driving down from the particular business, process and information domains, may quickly illuminate targets of opportunity for database or interface consolidation – and therefore potential consolidation of supporting technologies (i.e. storage, networking, processors). This may lead to optimized technical operations and business process performance, which can be clearly mapped back to the Enterprise Architecture to validate that governance and mission requirements are (still) met, cross-enterprise risks are mitigated, and IT investment portfolios and procurement activities are properly adjusted or re-aligned.

With this kind of information, a VECP could be constructed that very clearly proposes both program-specific and collateral (i.e. across the rest of the enterprise) savings resulting from introduction of state-of-the-art consolidating technologies (for example, pre-integrated, self-contained and consolidated database engineered systems, perhaps cloud-enabled). At the very least, an EA view can help identify and prioritize targets of opportunity for Value Engineering that may become part of an effective and timely sequestration response – both before and after such an event, and in fact as part of the annual capital planning and investment control (CPIC) processes.

7 years, 9 months ago

Move to Cloud Need Not Be Sensational

As the cloud computing adaption and maturity accelerates, a number of case studies of early cloud migration are emerging. Ironically most of such case studies often talk about success of such migration and dynamic business and technology benefits it de…

7 years, 9 months ago

The value of an Interface Catalogue

See also my more recent blog post http://coredataintegration.isys.bris.ac.uk/2013/06/16/important-documentation-for-soa-the-interface-catalogue-and-data-dictionary/ Part of Enterprise Architecture activity involves examining the “As Is” in terms of the organisation’s systems architecture and developing a vision and specification of the “To Be” systems architecture. Many systems are integrated with each other in terms of data – data is ideally stored once and […]

7 years, 9 months ago

Business Process Manifesto Published

The Business Process Manifesto edited by Roger Burlton is now available. The purpose of this manifesto is to create common definitions for terminology and concepts used in the business process management space. This document has been a number of years in the making and has received review and input from many business professionals worldwide. It

The post Business Process Manifesto Published appeared first on Louise A Harris on Enterprise Business Architecture.

7 years, 9 months ago

Where the CIO sits makes no difference to EA?

Photo titled “sit where you want”.  Pretty apt for this article!
(photo credit: DorteF)

Enterprise Architecture deals with the blueprint of enterprises, so it might make sense that the blueprint function sits close to the Chief Executive Officer in the organization chart to ensure alignment between planning and execution. Is there a correlation between where the Chief Enterprise Architect sits in the organization chart and the Enterprise Architecture maturity of that enterprise?

Figure 1 shows the data from an interview of almost 20 government agencies that included questions about their EA maturity as well as the number of layers between their CEO and Chief EA.  No clear pattern can be identified from the interview data.  Some might even argue that having two to four layers between the CEO and the Chief EA is the best!


Figure 1 Relationship between Chief EA’s distance to CEO and EA Maturity

In addition, my discussions with a researcher from Massachusetts Institute of Technology suggests the same finding: that there has been no support in data of correlation between an organization’s Chief EA’s proximity to the CEO and its EA maturity.

Does this mean that it does not matter where the chief EA sits in organizations? In many organizations, the Chief Information Officer is the chief EA, so does that also mean that it does not matter where the CIO sits in organizations?

Through the interviews, I noticed that the organizations who reported having mature EA roughly falls into three groups. The first group is made up of organizations with very influential CIOs who reported either directly into the CEO or to a direct report of the CEO. The second group has stories of their CEO believing strongly in EA, and pushed the EA agenda top-down. The third group consists of organizations that I was not clear why they reported high maturity for their EA. It might be a lack of understanding on my part, but I also suspect some of them are still early in their EA journey and thus not yet equipped to provide an accurate assessment of their EA maturity.

Analyzing the mature organizations gives the following thought: where the chief EA sits is less important to an organization’s EA maturity than EA’s mindshare among senior managers. If the CEO believes in EA, the organization is more likely to have mature EA. If the CIO is influential and believes in EA, it is more likely that he can influence the CEO to think the same. The challenge though is that it is difficult to measure EA’s mindshare among senior managers, but this does reinforce an often-repeated EA best practice on the importance of gaining top management’s sponsorship to achieve successful EA implementation.

7 years, 10 months ago

How do you reward failure?

I was a participant in a recent survey facilitated by the Corporate Executive Board’s Enterprise Architect community forum regarding “How do you reward failure?” My response to the survey triggered a bunch of emails from other members to me noting how much they liked my response so I thought it might be worthy to share…