A Net-centric Military and Enterprise Architecture

Information is central to the Department of Defense’s arsenal for fighting and defeating our enemies and the ability to share information across interoperable systems in the way ahead.

National Defense, March 2008 reports that while a net-centric military is our goal, the transformation is a work in progress.

Brig. Gen. David Warner, director of command and control at DISA stated: “in this war, information is truly our primary weapon. You can’t move, you can’t shoot, if you can’t communicate.”

Yet, “the Defense Department continues to acquire stovepiped systems…the requirements change, the system grows, and then there are cost overruns. One of the first items to cut from the budget is interoperability.”

Air Force Gen. Lance L. Smith says, “the dream of a truly net-centric U.S. military will not happen overnight. But progress could be achieved within the next five to 10 years, It will be a matter of waiting for the stovepiped legacy systems to come to the end of their lifespan. If the services get onboard and stop building non-interoperable technologies now, then the new generation of net-centric communications can take over and become the norm.”

This sounds to me like the problem isn’t limited to legacy systems, but that there are still cultural, project management, and change management issues that are obstacles to achieving the net-centric goal.

The challenges are even greater and more complex when it comes to sharing information with “federal civilian agencies and foreign allies…NATO, for example, has no mechanism to ensure its members are interoperable with each other.”

“Today the normal way to do business is to ‘exchange hostages’ which means sending personnel from one service, agency, or coalition partner to each other’s command centers so they can verbally relay information.” This typically takes the form of interagency operation command center, and is not very net-centric.

So we continue to have stovepipes for “communications or data sharing systems built by different agencies, armed services, or coalition partners that cannot link to each other…[yet] the U.S. military is trying to make itself more lethal, faster, and more survivable. [And] the key to doing that is the ability to share information.”

Net-centricity, interoperability, and information sharing are true cornerstones to what enterprise architecture is about, and it is where we as architects are needed to take center stage now and in the years ahead in the war on terrorism and the other challenges we will face.

From an EA perspective, we need to ensure that all of our agencies’ targets, transition plans, and IT governance structures not only include, but emphasize net-centricity and enforce it through the EA review processes and the investment review board. There is no excuse for these stovepipes to persist.

A Net-centric Military and Enterprise Architecture

To Be A CIO and Enterprise Architecture

Public CIO Magazine, June/July 2008, has some interesting articles on what it takes to be a next generation CIO (and many of these have to do with enterprise architecture).

Here are some tips (adapted from Public CIO):

• Develop your EA and IT Governance Capabilities—one of the first moves of Michael Locatis, the CIO of Colorado, was “hiring an enterprise architecture team leader and the development of new governance structures.” This is critical in effectively planning and change managing the consolidation of IT. In Colorado it means uniting “20 disparate IT departments into a single citywide Technology Services Division.”
• Be a strategist—Liza Massey, CEO of The CIO collaborative, a Las Vegas-based consultancy believes that a “CIO needs to make the leap from being a technologist to being a strategist [what EA planning is all about!]…’you have to be seen as a peer working for the good of the organization, not as the chief geek.’” She says, “if you know the version number of the operating system running on your mainframe, you’re probably not a CIO.”
• Understand that mission drives technology—Pat Schambach, retired CIO of the Secret Service, ATF, and the TSA said “it was his ability to understand his organization’s business imperatives that made him CIO material.” Pat states about the Service, “they wanted someone who knew the mission well and could bring technology to bear against that mission.” Again, this is good EA and IT governance in practice: where business drives technology and not doing technology for technology’s sake.
• Focus on business processes—Vivek Kundra, the CTO of Washington DC believes that “The key is to focus on the business process.” He stated, “My approach is to go after the core of the problem, to look at how the employees do their jobs and then look for how we can affect change.” Again, this is EA synthesizing business and technology to satisfy mission and end-user needs and requirements.
• “Behave like an enterprise”—Dave Wennergren, Deputy CIO for the Department of Defense and prior CIO of the Navy, said “we have to behave like an enterprise. We don’t need 50 smart card solutions or 50 collaboration tools.” He believes “the enterprise can be responsible for tools everyone uses, freeing up agency developers to work on tools specific to their needs.” In other words, we can leverage enterprise architecture and IT governance to develop enterprise solutions that are cost effective and efficient, but at the same time remain nimble in meeting niche or localized needs.
• Be able to translate business to technology and vice versa—Alan Shark, executive director for the Public Technology Institute said, “I’m seeing a big shift from issues that were purely technology to issues have much more to do with IT governance and leadership—being a translator between the technologists who work in the trenches and the politicians or the [higher-level] people who just want to hear the facts.” Again, EA plays a critical role here in synthesizing business and technology to enable better IT decision making for the mission/business.
• Leadership skills—In the latest survey of the National Association of State CIOs, the traits that rose to the top for CIO success: “communication skills, negotiation skills, being able to collaborate and work across the agencies, to work with their executive team.” Laura Fucci, the CIO of Clark County Nevada (home to the Las Vegas strip) echoes these sentiments for a CIO and talks in terms of team building [and networking], being a consensus builder, improving customer service (ITIL), studying metrics, and good project management.

A few other traits worth mentioning from David Wennergren, from DoD, is continuous learning and studying and driving best practices. This again ties strongly to enterprise architecture which builds the target architecture, transition plan, and IT strategic plan, bringing together the best practices from inside and outside the organization to move it steadily forward.

Clearly, the enterprise architecture is the foundation for a successful CIO and the organization he/she serves.

To Be A CIO and Enterprise Architecture

Earned Value Management and Enterprise Architecture

“Earned Value Management (EVM) is a project management technique used for measuring project progress in an objective manner. EVM combines measurements of technical performance (i.e., accomplishment of planned work), schedule performance (i.e., behind/ahead of schedule), and cost performance (i.e., under/over budget) within a single integrated methodology. When properly applied, EVM provides an early warning of performance problems.” (Wikipedia)

There is a terrific article on EVM called “If the Pharaoh Had Only Used An Earned Value System in Building the Pyramids,” by Lt. Col. William Neimann USAF (Ret.) Lt. Col. Neimann demonstrates very effectively how to use EVM (a scary topic to many) in a humorous scenario of ancient Egypt and the building of the pyramids.

The article starts as follows:

"The developer of the great pyramid of Egypt might be looked upon as the father of program management. He had one of the first programs in recorded history that required a great deal of integration and coordination (i.e. program management). He did not, however, have the relatively new concept of "earned value" to assist in the management of this ambitious program. An "earned value" concept is the heart of all defense contractor management information systems, which comply with DoD Instruction 5000.2 concerning the earned value management control system (EVMCS). But let's go back nearly 5,000 years to the construction of the pyramids to see if "earned value" would have been of any utility in managing that program.”

So what are the key measures in EVM for identifying cost and schedule variances?

(Positive is favorable, Negative is unfavorable)

• Cost Variance (CV) = Budgeted Cost for Work Performed (BCWP) - Actual Cost for Work Performed (ACWP)

So, if the Pharaoh’s project manager budgeted 14 million shekels for the pyramid construction, but actual cost came in at 13 million shekel, then the project has a positive or favorable cost variance of 1 million shekels. The pyramids are under budget.

• Schedule Variance (SV) = Budgeted Cost for Work Performed (BCWP) – Budgeted Cost for Work Scheduled (BCWS)

So, if Pharaoh’s project manager calculates that work performed was budgeted at $10 million shekels, but was scheduled to be 14 million shekels complete, then the project has a negative or unfavorable schedule variance of 4 million shekels. In other words, the pyramid builders have performed 4 million less work than planned. The pyramids are that behind schedule.

To calculate the overall project status at any given time:

• % Schedule = (Budgeted Cost for Work Scheduled (BCWS)/Budget At Completion (BAC)) * 100
• % Complete = (Budgeted Cost for Work Performed (BCWP)/Budget At Completion (BAC)) * 100
• % Spent = (Actual Cost for Work Performed (ACWP)/Budget At Completion (BAC)) * 100

How efficient is the project?

Greater than 1 is favorable, less than 1 us unfavorable:

• Cost efficiency = Budgeted Cost for Work Performed (BCWP)/Actual Cost for Work Performed (ACWP)
• Schedule efficiency = Budgeted Cost for Work Performed (BCWP)/Budgeted Cost for Work Scheduled (BCWS)

(Adapted from Earned Value Management Gold Card, Defense Acquisition University)

There are a number of other measures, but you get the idea.

EVM is important to Enterprise Architecture, why?

Enterprise architecture planning and IT governance is all about making order out of chaos in managing IT. By setting strategic direction with the architecture and enforcing it with sound governance, we set the stage for more successful IT project delivery. EVM is a way to measure IT projects success in terms of cost, schedule, and performance. Through EVM, we can measure our IT projects to ensure that we are meeting our EA plan and making course corrections as necessary through the governance process.

EA, IT governance, and EVM are ways to ensure that we no longer manage IT by the “seat of our pants” approach (gut, intuition, politics, and subjective management whim). We now have tools to plan, govern, and measure transformation.

Earned Value Management and Enterprise Architecture

Why IT Governance and Enterprise Architecture

I came across an excellent white paper by the National Association of the State CIOs (NASCIO) on IT governance that goes through the fundamentals.

What is IT governance?

IT governance is “specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.”

Sound IT governance helps to ensure effective use of IT resources, “avoid unnecessary or redundant investments,” more successfully deliver IT solutions, and “enhance appropriate cross-boundary interoperability.”

Why is IT governance ever more important?

According to Gartner, the net average ROI for IT projects is only 1% and as of 2002, “20% of all expenditures on IT were wasted.”

“Information management approaches used during previous eras are no longer sufficient.”

“Information technology is no longer restricted to simply automating procedures, or even managing information, rather, information technology now enables and even outstrips an enterprise organizational capabilities for transformation.”

We “continue to depend more and more on information technology to achieve efficiencies, collaborative information sharing, business intelligence, and information socialization.”

Who should be involved in IT governance?

“Proper IT governance requires a highly participative collaboration between…CIOs and executive leadership on the business side.”

“Pure technology decisions will be primarily made by leadership with information technology with consulting input from the business. Pure business decision making will be primarily made by business leadership with consulting input from the…CIO. However, in most cases, determination of where and when to employ technology will be a shared responsibility.”

This is the piece that I liked the best—the convergence of the necessity for sound IT governance with robust enterprise architecture is what it takes to truly yield results. As the paper states: “In fact, information technology properly managed and deployed within the umbrella of enterprise architecture will provide the path to transformation.”

Why IT Governance and Enterprise Architecture

Circumventing the CIO—What’s the Harm?

One of the most difficult challenges we face as enterprise architects is when end-users don’t ask permission, but instead ask forgiveness.

The typical scenario is that a division or unit or group of end-users decides to go out and purchase some new IT widget, gadget, or system without going through the CIO shop. (I know this shouldn’t happen if the CIO controls the IT funding, but even then someone always finds some money squirreled away and decides to use it for something they weren’t supposed to or in some cases even bypasses the money channels altogether, getting a freebie from a eager vendor looking to build or test some new capabilities to sell later to other customers).

Well, where’s the harm?

Oh my G-d, where should I start…

Innovation from the field and operators is great, but bypassing the CIO shop circumvents the structured processes and good governance that is in place to ensure projects succeed. Without these mechanisms, IT project can be at tremendous risk:

1. Business Case—Without a business case, the justification for the IT project was never made, return on investment not calculated, alternatives not considered, and the best course ahead not properly laid.
2. Investment Review Board—Without IRB vetting, the senior-level sponsorship has not been solidified, the project has not been authorized, and its priority has not been set with respect to other, maybe more critical, projects that the enterprise needs; further, the project may not have adequate life cycle funding; additionally, the project is likely not being ongoingly monitored and managed by leadership and enterprise subject matter experts for cost, schedule, and performance.
3. Enterprise Architecture Review—Without an EA technical review, the IT project may align with the target architecture and transition plan, may not be interoperable with other systems, may not meet enterprise technical standards, may overload or be incompatible with existing infrastructure, may be duplicative of other investments, may not be the best or most cost-effective technical solution, may not meet various legal, regulatory, and other compliance requirements.
4. System Development Life Cycle—Without following a defined, repeatable, and measureable SDLC process, the project risks failure by not having adequate and documented planning and requirements, design, development, testing, implementation, training, operation and maintenance, and disposition.
5. Project Management Plan—Without a project management plan, projects are at risks for being mismanaged, having cost-overruns, schedule delays, and quality problems.
6. IT Security Plan—Without an IT security plan, the project is at risk in terms of the confidentiality, integrity, availability, and privacy of the information.

No question, from an end-users perspective, there are quite a few hurdles to go through in implementing a new IT project. An if we’re honest with ourselves, the process can be onerous. Therefore, the CIO and his staff needs to work to streamline the processes, integrate them, provide the users with job aids and excellent customer support. Additionally, there should be a quick pass process for getting those “emergency” (must have now) projects through quickly (although not any less comprehensively).

The key is to balance the needs of the enterprise (ensuring mission execution and sound stewardship of enterprise resources), end-users (supporting innovation and operators ability to do their jobs successfully and safely), and customers or citizens (bringing new products or services to market quickly, reliably, and at high quality levels). To do this we have to balance the necessary processes and governance to ensure IT projects’ success with the imperative to foster innovation and deliver quality and speedily to market.

So as an enterprise architect, what do you do when a end-user asks forgiveness, instead of permission?

Circumventing the CIO—What’s the Harm?

IT Projects - Get It Right or Fix It Later?

The Wall Street Journal 25 September 2007 reports on a new model being called the “wave of the future”, where IT projects are rolled out “on schedule…even if all the kinks haven’t been worked out” and then fix it later, as problems arise.

The idea of this model is that by rolling out and fixing problems on the fly, you avoid extensive schedule delays and cost-overruns common with IT projects.

Arizona University followed this model in rolling out their enterprise resource planning (ERP) system and it was hailed as “highly successful” by a VP at Oracle, even though “there were payroll mistakes that left some [3000!] workers unpaid, underpaid, or overpaid.”

“Oracle hailed it as a model for both universities and corporations to follow.” The strategy is to “implement, adapt, grow.”

This model of fix it later is being used by “Internet companies like Google Inc. These companies label the software they release ‘beta,’ meaning that it is good enough to use, but it isn’t finished. Sometimes they keep it that way for years, using feedback from users to create ever more-refined versions.”

In the fix it later model, you “admit from the start that there will be mistakes; then work through the glitches [after rollout] with users’ help. This is the opposite of the traditional model that says companies “take their time and don’t start using a new computer system until they are convinced almost everything works right.”

Which approach is better?

From a User-centric Enterprise Architecture point of view, we have to balance two competing drivers.

• One is the importance of meeting user needs and mission requirements, and this means that we don’t delay important IT rollouts unnecessarily, incurring schedule delays, cost overruns, and unmet requirements—This sides with the Fix It Later model.
• On the other hand, we don’t compromise the mission by taking unnecessary risks and rolling out IT systems that are not tested ready and reliable—This sides with the Get It Right model.

Perhaps, the best IT model is a hybrid that I would call—“Get It Right, On Schedule and Within Budget!”

IT Projects - Get It Right or Fix It Later?

Use Cases and Enterprise Architecture

User-centric EA fulfills many different needs (as portrayed through Use Cases) in the enterprise.

In the Journal of Enterprise Architecture (JEA), August 2007, the authors of the article “Analysis and Application Scenarios of Enterprise Architecture: An Exploratory Study” (Winters, Bucher, Fischer, and Kurpjuweit) provide a variety of these “application scenarios” for EA.

Use Cases can help us understand the importance and benefits of Enterprise Architecture by showing its application to real-world scenarios. Below is a list of key use cases for EA (adapted from JEA):

1. Adoption of Commercial and Government Off-The-Shelf Software (COTS/GOTS)—informs on enterprise IT products and technical standards for integration, interoperability, and standardization.
2. Business Continuity Planning—identifying the dependencies between business processes, application systems, and IT infrastructure for continuity of operations.
3. Business Process Optimization—reengineering or improving business processes based on modeling of the business processes, the information required to perform those, and the technology solutions to support those.
4. Compliance Management—helps verify compliance with legal requirements such as privacy, FOIA, Section 508, records management, FISMA, and so on.
5. Investment Management—supports Investment Review Board; determines business and technical alignment and architecture assessment of new IT investments.
6. IT Business Alignment—aligning IT with “business, strategies, goals, and needs.”
7. IT Consolidation—“reveals costly multi-platform strategies and wasted IT resources originating from personal preferences of certain IT stakeholders and/or a lack of enterprise-wide coordination.”
8. IT Planning—develops target architecture and transition plan; develops or supports IT strategic plan and tactical plans.
9. Performance Management—Management of IT Operations Costs through the development of IT performance measures to manage IT resources.
10. Portfolio Management—categorizes IT investments into portfolios and prioritizes those based on strategic alignment to the target architecture and transition plan.
11. Post Merger and Acquisition Integration—identifies gaps, redundancies, and opportunities in business processes, organizational structures, applications systems, and information technologies.
12. Procurement Management—aids sourcing decisions; specifies standards, provides reviews of new IT investments.
13. Project (Initialization) Management—specifies projects requirements, looks at the potential for existing systems to meet user needs, and avoids redundant development activities.
14. Quality Management—document business processes, information requirements, and supporting IT; helps ensure performance.
15. Risk Management—managing technology risks; understanding which technology platforms support which business processes.
16. Security Management—documenting business and IT security and defining user roles and access rights.

When done right, EA helps to create “order out of chaos” for the execution of business and IT in the organization.

Use Cases and Enterprise Architecture

Getting Performance Metrics Right

Architecture and Governance Magazine, Volume 3, Issue 3 has a great piece on developing “Metrics that Matter”.

The idea is that metrics are a critical management tool for tracking, managing, and ultimately, changing organizational behavior!

All too often, organizations do not develop or keep metrics on anything below a top-level organizational view, and even then just develop metrics that either make them look good (i.e. the metrics are very achievable) or that are easy to measure (i.e. the measures are readily available from existing data).

Organizations cannot really drive improved performance if they do not measure systemically and strategically thoughout the enterprise!

For IT metrics, Architecture and Governance Magazine proposes that we use three core categories of metrics:

1. Strategic Value—The most difficult area to measure, but one of the most valuable from the business point of view; it “identifies the degree of a business unit’s effective use of technology,” to achieve mission execution and and results of operation.
2. Project Management Effectiveness—this should “cover the quality, scope, and milestones…includes schedule adherence, functional delivery requirement specifications, and—the least often measured—return on investment for several years after deployment.”
3. Operational Effectiveness (And Efficiency)—effectiveness, which is the more important metric, involves measuring such things as customer satisfaction, cost-savings, income generation, or ehanced mission capabilities; efficiency, on the other hand, is where IT leaders often “drown executives in operational data such as help-desk resolution times and network uptimes—data that is meaningless to the corporate strategy and cements IT’s reputation as being little more than a janitorial service for technical systems.” Additionally, “if they demonstrate only efficiency, they play into the bean-counter mentality that all that matters is extracting more efficiency from the system. That’s an easy road to continued cuts…‘this cost focus had led to the suboptimatization of IT’…[and] can even lead to the eventual outsourcing of IT.”

In general, emphasize the top 2 categories of measures, and focus only on the 3^rd “if the IT department has a history of failure and thus needs to be closely monitored on the basics.”

Finally, “a good rule of thumb is that there should be less than a half-dozen key metrics provided to executives…if they need more detail, provide the drill-down capabilities, but don’t make it part of the standard report.”

In User-centric EA, performance metrics are one of the primary perspectives of the enterprise architecture (which include performance, business, information, service, technology, security, — and human capital, in the future). The performance measurement view of EA is the pinnacle of the architecture, where we identify mission execution and results of operation goals and then track and manage to these. The performance measures cascade throughout the organization to build performance results, bottom-up, to achieve mission execution and the performance goals set at the highest levels.

Additionally, IT needs to take a front position (i.e. lead by example) in developing and managing to solid performance measures that not only demonstrate the effectiveness of its utility operations, but that demonstrates effective management of new IT investment dollars to bring new and enhanced capabilities to the end-users and most importantly, that it adds to the strategic results of the enterprise.

Getting Performance Metrics Right

Murphy’s Law and Enterprise Architecture

Murphy's law is an adage in Western culture that broadly states that things will go wrong in any given situation, if you give them a chance...It is most often cited as "Whatever can go wrong, will go wrong" (or, alternately, "Whatever can go wrong will go wrong, and at the worst possible time, in the worst possible way”)...The saying is sometimes referred to as Sod's law or Finagle's law which can also be rendered as "Anything that can go wrong, will—at the worst possible moment". (adapted from Wikipedia)

Well Murphy’s Law is pretty pessimistic and ominous, but I guess for those of us who are old enough to have lived through some of life’s up’s and down’s (and Murphy’s Law would probably say they’re mostly downs), then the adage is not only meaningful, but also a cautionary tale for how we conduct ourselves.

No, It’s not about being paranoid or schizoid or any of those things.

But probably more a big “WATCH OUT!” or “KEEP YOUR EYES OPEN!” sign plastered along the bumpy, curvy road of life.

One of my old pals has a spin of Murphy’s Law (although I don’t think he see it quite that way) that goes like this: “Man plans and G-d laughs.”

As a manager, I see Murphy’s Law as part of good program and project management. It’s about planning, planning, and more planning (sustained and determined), with plenty of risk management built in as you execute and deliver to the customer on behalf of the enterprise.

But even with planning and risk management, you can never cover every eventuality. What you can do is try to prevent or avoid certain risks, mitigate others, and accept the ones you can’t avoid or mitigate. Pretty much, simple as that.

User-centric EA is a process for the enterprise to plan and manage risk—all those inherent in Murphy’s Law. EA does this by formulating, documenting and communicating where the organization is at, where it is headed, and how it is going to try and get there. Furher, it vets these plans with leaderhip and subject matter experts, builds consensus, and drives positive, incremental change. EA helps the organization adapt to changes internally and externally. EA is a bulwark against the law of “anything that can go wrong, will.”

Murphy’s Law and Enterprise Architecture

Enterprise Architecture: Program or Project?

Enterprise Architecture is a program with many phases and projects.

Several times in my career, I have been brought in to develop an enterprise architecture for an organization, and just about every time, the boss has asked how long will it take, when will it be done, or some other similar version to time-bind the effort.

However, for those of us who are practitioners in the field of EA, we know resolutely the answer is that EA is never done.

Legally, EA is mandated by the Information Technology Management Reform Act (a.k.a. the Clinger-Cohen Act). As such, it is not a one-time event, but an ongoing requirement, and thus an established program in every department of the federal government.

But more than that, EA defines the current, target, and transition plans for an organization. And by definition, a current and target are just snapshots in time, which are in essence outdated a moment after you publish (just like when you drive a new car off the dealer lot and it immediately becomes “used.”) That is, an organization, its business and technology, are constantly evolving and in a state of flux, responding to internal and external factors (such as new mission challenges, business opportunities, congressional or executive mandates, changing customer expectations, new technologies, and so on). So in an ever-evolving organization, the “current” state does not stay current, and the “target” does not stay current (up to date). That is, unless you place these under “maintenance,” i.e. you refresh these on a periodic basis, and make course corrections along the way.

Further, developing and maintaining an EA for any organization is a challenging task, especially for a large and complex organization (like many in the federal government). As such, EA efforts need to be broken down into smaller projects to be successful. And these projects need to be clearly defined in terms of scope, schedule, and performance measures and managed for all project knowledge areas (reference: Project Management Book of Knowledge).

So the next time your boss asks you, “When will the EA be done?” I suggest you tell them: “The EA is a program with many phases and projects. Phase (#) is scheduled to roll out (date).”

Has this ever happened to you – that your boss asked you when the EA would be finished? What did you say/do?

Enterprise Architecture: Program or Project?