>HSPD-12 and Enterprise Architecture

>

Homeland Security Presidential Directive 12, 27 August 2004, is a “Policy for a Common Identification Standard for Federal Employees and Contractors.”

HSPD-12 establishes a mandatory, Government-wide standard for secure and reliable forms of identification issued by the Federal Government to its employees and contractors (including contractor employees).

The policy mandates promulgation and implementation of secure, reliable identification that covers Federally controlled facilities, Federally controlled information systems, and other Federal applications that are important for security. “Secure and reliable forms of identification” for purposes of this directive means identification that (a) is issued based on sound criteria for verifying an individual employee’s identity; (b) is strongly resistant to identity fraud, tampering, counterfeiting, and terrorist exploitation; (c) can be rapidly authenticated electronically; and (d) is issued only by providers whose reliability has been established by an official accreditation process. The Standard will include graduated criteria, from least secure to most secure, to ensure flexibility in selecting the appropriate level of security for each application.”

In Government Computer News, 27 October 2007, Jack Jones, the CIO of the National Institute of Health (and Warren Suss, contractor) discuss how NIH leveraged the mandates of HSPD-12 to not only implement the common identification standard for more than 18,000 federal employees [and another 18,000 part time employees, contractors, fellows, and grant reviewers] on its main campus in Bethesda, Md., and at satellite sites nationwide,” but also modified and improved it’s business processes to ensure a holistic and successful architectural implementation.

What business modifications were involved?

HSPD-12 was a catalyst for change at the institutes. The NIH Enterprise Directory (NED), which automated the process for registering and distributing badges to new NIH employees, needed to be revised to comply with HSPD-12…the conversation led to a re-examination of the broader set of processes involved in bringing a new employee onboard. In addition to registering new employees and issuing badges, NIH, like other federal agencies, must assign e-mail addresses, add new employees to multiple agency mailing lists, order new phones, assign new phone numbers and update the phone directory.”

How did NIH address this using enterprise architecture?

NIH changed its enterprise architecture through a formal, facilitated business modeling process that involved all NIH stakeholder groups. The results included clarifications in the policies and procedures for processing new employees along with the transformation of NED into a significantly improved tool to support better communication and collaboration in the broad NIH community.”

From a User-centric EA perspective, this is a great example of EA supporting successful organizational change. NIH, like other federal agencies, was faced with the mandates of HSPD-12, and rather than just go out and procure a new system to meet the requirement, NIH used EA as a tool to look at its entire process for provisioning for new employees including policy. NIT EA modeled it business processes and made necessary modifications, and ensured a successful implementation of the identification system that is supported by sound business process and policy. Additionally, the CIO and the EA did not do this in some ivory tower, but rather in a collaborative “workshops with NIH stakeholder groups”. This collaboration with stakeholders hits on the essence of what User-centric EA is all about and how powerful it can be.

>Immortality and Enterprise Architecture

>

In the book The Denial of Death by Ernest Becker, the author states: “Among all the animals, we alone are conscious of the fact that we will die, and we are obliged to spend our lives with knowledge of the paradox that while we may be capable of G-d-like spiritual transcendence beyond our bodies, our existence is dependent on a finite structure of flesh and bone that will ultimately wither away and disappear.” Becker believes that we deny the reality of death by pushing the fear of it into our deep unconscious.

Gareth Morgan, in the book Images of Organization, explains how the denial of death manifests itself not only in the individual, but also in the organization’s “quest for immortality.” “In creating organizations, we create structures of activity that are larger than life and that often survive for generations. And in becoming identified with such organizations, we ourselves find meaning and permanence.”

People and organizations want to “preserve the myth of immortality” by “creating a world that can be perceived as objective and real.” “This illusion of realness helps to disguise our unconscious fear that everything is highly vulnerable and transitory.”

How does EA deal with the “myth of immortality” of the organization?

Enterprise architecture is a forward looking discipline. EA takes the current state of the organization and develops a target and transition plan. However, when EA looks forward, does it acknowledge the ultimate mortality of the organization or does it seek to perpetuate the organization indefinitely?

Of course, as employees of the organization, our job is to do the best for the organization we work for: to plan and work for its survival, and more so, its growth, maturation, and ultimate competitiveness.

However, if as architects, we see that the organization will not be competitive and survive in its current form, then we need to acknowledge that reality. As architects, we are in a somewhat unique position to help remake and transform the organization so that it can live on and prosper. We can do this by envisioning a new state and planning for changes in what the organization does and/or how they do it. We can do this through process reengineering, new technologies, or a more drastic “organization makeover” in terms of a new/revised mission, strategy, leadership, and so on. Unlike a human being, whose life is fleeting, an organization can either die or be reborn again to live and compete another day.

>Customization and Enterprise Architecture

>

While User-centric EA seeks to provide useful and useable products and services to the end-user, the heavy customization of major application systems to meet user needs is a huge mistake. Major customization of IT systems is a killer: it is a killer of the application and a killer of the underlying business processes.


What do I mean? When you heavily customize an application system (and I am not talking about changing settings), you do the following:
  • You greatly increase the implementation cost of the system, since you have now added all sorts of modifications to the system.
  • You greatly increase you maintenance burden, because new versions of the software often will need to be recoded.
  • You hamper the ability of the system to interoperate with other systems that it was designed to work with (even when it is built with open standards), since you have tinkered and tweaked away at it.
  • You missed one of the biggest opportunities to improve and reengineer your business processes; instead of aligning your business processes with those identified (by usually hundreds, if not thousands of other organizations) as best practices and written into the software, you have made your enterprise the odd man out and overwrote the best practices in the application system with your specific way of doing things. That’s a big no-no.

Let’s face it, most (and there are exceptions to every rule) organizations at their fundamental “business” (not mission) practices are often close to identical. Areas like finance, human capital, and even IT and considered utilities to the organization. These areas are often run in ways to exploit enterprise solutions for large organizations (for example, one timekeeping system, one payroll system, or one general ledger system ) and these functions are the first to be looked at for integration and downsizing on the corporate side during mergers and acquisitions.

Instead of insisting that your processes are so different, see why others are doing it another way and whether there is merit in it, before you go and customize and chip-away at the system—you may be doing yourself more harm than good. Generally (and there are exceptions to every rule), you’re better off changing business processes to meet widely used and verified software.

>Monopoly and Enterprise Architecture

>

Monopoly─“a board game published by Parker Brothers, an imprint of Hasbro.…since Charles Darrow patented the game in 1935, approximately 750 million people have played the game, making it “the most played [commercial] board game in the world.” (Wikipedia)

Now according to The Washington Post, 15 December 2007, the classic board game is getting a technology makeover.

Monopoly “is one of the most popular games ever…its colored stacks of money─from the white $1 bills to the coveted bright orange $500 bills—have iconic status.”

Yet, even this classic game is being re-architected for the 21st century. In a new edition of Monopoly released this year, electronic bank cards replace colored money and the processes to track your game’s transactions has been reengineered and replaces good old-fashioned counting and scorekeeping.

The changeover in the game of Monopoly is mimicked in the new game of Life, Twists & Turns, and is a reflection of the change in society from being currency-based (with bills and change) to credit and debit cards. As a senior analyst at a consumer behavior research firm states: “I think this is a case of updating the game play/design to reflect the times.”

These days, “our wealth (or lack thereof) becomes just a number, printed on a bland receipt spit out from an ATM.” Moreover, “cash has become such a hassle that it is a nuisance even in our imaginations.” Imagine that: saying the cash is a nuisance (I bet that is a nuisance that a lot of people would like to get their hands on. J)

So Hasbro has reinvented the game to reflect changes in our society. This is a clear case of technology (electronic bank cards) being applied to a business problem (the out-datedness of the paper-based currency in the game). This is enterprise architecture and consumer marketing at work together and in tandem.

If even the Monopoly game that I used to play with as a kid can be refashioned with some good ‘ol doses of EA, imagine what EA can do for other businesses, products, and services. Reengineering business processes and applying technology to improve outcomes is a plus for board games, but an even stronger medicine for organizations and our economy.

>UPS is Enterprise Architecture Fait Accompli

>

Fortune Magazine, 12 November 2007, has an amazing article about UPS ( a company which last year had $47.5 billion in revenue and 100,000 driving jobs)—they are a flawless example of the integration of people, process, technology, training, and a keen customer focus; a shining example of what enterprise architecture hopes to instill in the organization!

  1. People—“UPS drivers make an average of $75,000 a year, plus an average of $20,000 in health-care benefits and pension, well above the norm for comparable positions at other freight companies.”
  2. Process—UPS relies on “human engineering” and has “’340 methods’, a detailed manual of rules and routines” that is taught to UPS’s legions of driver candidates. Moreover, detailed metrics are kept on trainees and throughout their professional career at UPS, so that “a supervisor meeting a new driver for the first time will know every single possible thing there is to know about him.”
  3. Technology— UPS has the delivery information acquisition device (DIAD), their electronic clipboard, “which is GPS-enabled, plans drivers’ routes, records all their deliverables, and is said to rival the iPhone in capability.”
  4. Training—UPS has opened a new full-service training center, a $34 million, 11,500 square-foot facility, called Integrad. “The facility and curriculum have been shaped over here years by more than 170 people, including UPS executives professors, and design students at Virginia Tech, a team at MIT, forecasters at the Institute for the Future, and animators at an Indian company called Brainvisa.” The facility even has a “slip-and-fall simulator” to safely prepare trainees bodies to be alert to falls, and a UPS “package car” with see-through sides, sensors to measures that forces on trainees joints, and videocameras to record their movements as they lift and lower packages.”
  5. Customer—“What’s new about the company now is that our teaching style matches your learning style. But we’re still taking care of the customer.” UPS is “the world’s largest package–delivery company…delivering an average of over 15 million packages a day.”

“While customers may be at the heart of UPSs business, it’s drivers who are at the heart of UPS itself…watch closely and those deliveries [are] an exhibition of routines so precise they never vary, limbs so trained they need no direction, and words so long remembered, they are like one’s own thoughts.”

UPS has mastered all of the following enterprise architecture aspects or perspectives:

  • BUSINESS—the precision of honed business processes (“340 methods”)
  • PERFORMANCE—the measurement of every critical management aspect, especially as it relates to their all important drivers and their deliveries.
  • INFORMATION—UPS is an information-driven company that captures information, analyzes information, and uses it to train and refine their personnel and operations.
  • SERVICES—business services such as delivery and training are best practice and tailored to meet customer and employee needs.
  • TECHNOLOGY—the UPS electronic clipboard enables the information capture and provision that is needed to continuously meet mission requirements.

While, I don’t love their brown uniforms (that is supposed to hide dirt), to me the successful integration and implementation by UPS of these core architecture factors makes it a case study for EA!

>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.