>We Can’t Ignore or Fear Technology For Long

>

New Article by Andy Blumenthal in Architecture and Governance Magazine (April 2010)

http://tinyurl.com/y3xgrlb

__________________________________

When it comes to new technology, first comes ignorance, then comes fear, then comes the embrace and rush to the IT department to make it happen—now!

This scenario plays out again and again in organizations—there are three key phases to technology adoption.

Ignorance—people are unaware, misinformed, or just don’t understand the potential that a new technology holds. In some cases, it’s because they generally haven’t been exposed to the technology, in other cases, it is because they are going forward with eyes wide-shut (what they don’t know can’t harm them or so they think).

Fear—OMG. A new technology; I can’t deal with this. “I’m used to doing it X way.” “Why do we have to change.” “I can’t learn this new technology.” There is fear of something new, of change, of the unknown.

Embrace—The acknowledgement that a new technology is important to the organization; that it can’t be ignored; that it isn’t going away; that the competitors are already getting onboard. Oh uh. Get the CIO in here. We need this technology, now! Where are we going to find finding for it this year (or quarter, whatever). We need to reprioritize our IT projects, so this is at the top (or near it). Let’s get everyone right on this. Can we meet early this week?

I read an interesting article in Public CIO magazine (January 2010) called “A Mile Wide And An Inch Deep,” about how social media is becoming pervasive in government.

In the article it states: “Last year, a Public CIO reader survey found that social media didn’t make the list of the top 10 technology priorities for 2009. Today, it’s become the No. 1 topic among public CIOs.”

In between not making the top 10 technology list and becoming No. 1, social media was vilified as being something that would make the organization lose control of its message, that was a security risk, and that was a colossal waste of employees’ time and should be banned (or blocked and it was by 40% of organizations).

As the pace of technology innovation increases, the lifecycle of adoption has also rapidly advanced. For example, with social media, we went from ignorance to fear to the embrace in one year flat!

Chris Curran, chief technology officer for Diamond Management and Technology Consultants Inc., is quoted in the article as stating:

“If you rewind to 1995, the attitude back then was, “No Internet use at work.” Then it became, “No Internet shopping during work hours.” But over time, the issue just went away, because a majority of employees are good people, hardworking and productive. Some people are going to do stupid things whether they have access to social networking or not. But it doesn’t make sense to ignore a social trend that is bigger than your organization.”

You can’t ignore important new technologies or let fear get the better of you. At one time, people were saying oh no we can’t change from paper communications to email. We need everything hardcopy. And that changed. Now email is the norm or should I say was the norm, because social computing for the younger generation is becoming the new email.

The answer for IT leaders to advance organizational adoption of valuable new technologies is to:

· Create awareness and understanding of new technologies—the benefits and the risks (and how they will be mitigated).

· Establish sound planning and IT governance processes for capturing business requirements and aligning new technologies to best meet these.

· Provide new technologies coupled with ample communications and training to ensure that the technologies are not just more shelfware, but that they are readily adopted and fulfill their potential in the organization to advance the mission and productivity.

The phases of technology adoption: Ignorance, fear, and embrace are not abnormal or bad; they are human. And as people, we must have time to recognize and adjust to change. You can’t force technology down people’s throats (proverbially speaking) and you can’t command organizational readiness and poof, there it is. But rather, as IT leaders, we need to be sensitive to where people and organizations are at on the adoption lifecycle and help to identify those emerging technologies with genuine net benefits that can’t be ignored or feared—they must be embraced and the sooner the better for the organization, its people, and all its stakeholders.

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

>SOA – Does the Emperor Have Clothes?

>

Architecture and Governance Magazine, Volume 3 Issue 3, reports that one of the Top 10 Challenges in Enterprise Architecture is “Getting Ready for Service-Oriented Architecture (SOA)”.

– Why is SOA proving to be such a challenge?

The article reports that “most architects have not done much of either substance or significance in this area.” Further, “most of what enterprise architects have addressed in this space concerns aligning IT with the business and governance”—and this is something that EA has been doing all along anyway.

– So what has SOA changed?

“What has changed is the promise of abstracting services that can be reused.”

However, some have questioned SOA:

  1. Is SOA “just a revival of modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)”?
  2. Is SOA “just another term for Web Services”?
  3. Is SOA “merely an obvious evolution of currently well-deployed architecture (open interfaces, etc.)”? (Wikipedia)

Others have questioned if SOA and EA are even distinct disciplines?

“So, has SOA in fact evolved into EA? A to question to which the answer is yes and no.” The author continues, “essentially there are three evolutionary paths:

  1. EA is absorbed by SOA
  2. SOA is absorbed by EA
  3. EA / SOA merge into a new concept”

Finally, the authors propose #3 merging EA and SOA as follows:

“SOA-A+EA = SOEA”

With the conclusion that “in order to create this holistic view EA and SOA must not be seen as separate disciplines, but to see the two as one will bring changes on such a scale that we are now talking about SOEA Service Oriented Enterprise Architecture.” (Journal of Enterprise Architecture, August 2007, Rasmus Knippel and Bo Skytte)

While the authors apparently seems to think SOA is important (although they call it “increasingly more abstract”), the relationship to EA is changing and unclear—Not sure this idea about SOEA is helpful at this juncture!

– How helpful to SOA development is the guidance from the Federal Enterprise Architecture (FEA), Service Reference Model (SRM), which talks about services and capabilities?

Not very! The SRM is supposed to “provide a high-level view of the services and capabilities that support enterprise and organizational process and applications.” (FEA, SRM). However, the service domains, service types, and capabilities listed in the FEA SRM are quite muddy, at best. Here is an example:

  • The domain of Process Automation is defined as “the set of capabilities that support the automation of process” [hasn’t every 5th grader been taught not to define a term with the same term?]
  • And it continues “and management that assists in effectively managing the business” [well that is a pretty broad definition— can’t all services assist in effectively managing the business?].
  • Then after the definition, you’re expecting some pretty extensive process automation services, but the SRM lists just 2 components:
  1. Tracking and Workflow (which includes capabilities like case management [what’s that doing here?] and conflict resolution [isn’t that a leadership skill set?])
  2. Routing and Scheduling, which includes just Inbound and Outbound Correspondence Management [so where the scheduling piece like calendaring or time management that one normally associates with scheduling and how does the routing as in Routing and Scheduling reflect the routing inherent in Tracking and Workflow category above—seems like some category overlap]

I’ll let you look at the SRM yourself to see evaluate the clarity of the other categories, but they are pretty much the same. Ok, I can’t resist, here’s one more:

  • The domain called Business Management Services, after the domain of Process Automation, actually has a service type in it called management of process {why isn’t this in the process automation domain?].
  • The other service types in this domain include Organizational Management [that includes workgroup/groupware and network management, huh?]
  • And Investment Management [ok]
  • And Supply Chain Management [which includes things like procurement, Warehousing, and Inventory Management— so why isn’t this part of back office services, like Finance, Human Capital, and Asset/Material Management?]

If this looks confusing, you’ve got my point, it’s because the FEA SRM is confusing.

– So what’s an enterprise architect to do?

Architecture and Governance Magazine says, enterprise architects need to take back the high ground here—and that must be done in 2007…today’s enterprise architect must re-engage with all the principals in the enterprise by making a case for seeing service and technology architectures as one.”— this is good advice, I suppose, but also more than a little vague!

I’ve seen a bunch of presentations (including a recent one from Department of Education) where EA has tied IT services (pretty much their IT portfolio) to requested business capabilities—again it seems pretty much like what EA is or should have been doing all along, aligning business and technology investments with a focus on reducing gaps, redundancies, and inefficiencies.

I’ve seen other people including some prominent computer and consulting vendors present this topic as well, and aside from pushing there wares, have seen them fall all over themselves tying to define and explain SOA. Honestly, it was pathetic!

Finally, I have seen one impressive implementation at a government agency, and it did actually have savings associated with it, but the application was done a few years back, was relatively small, and there has been little to no movement on further SOA development since (except for the purchase of an enterprise service bus) even though there is a mandate in this agency to implement SOA.

In fact, at a recent meeting with the business side from operations, the presenters said that they were going to spend oodles of money rewriting one (if not the) major operational application for the agency (over 1.2 million lines of code and growing) to make it .NET compliant. I asked the business if they were going to take this opportunity to do this using SOA, and they said no, they just want the same functionality as before!

So in the end, if the business doesn’t want it and the vendors and consultants can’t explain it, the final question with SOA is does the emperor really have clothes?

>SDLC, CPIC, PMBOK, and EA

>

User-centric EA seeks to align the various life cycle IT system processes to help users understand, navigate, and complete these as simply and smoothly as possible.

Below is an alignment of the processes for System Development Life Cycle (SDLC), Capital Planning and Investment Control (CPIC), Enterprise Architecture (EA), and the Project Management Book of Knowledge (PMBOK).

SDLC

CPIC

EA

PMBOK

Conceptual Planning

Select

Business Alignment

Initiating

Planning & Requirements

Control

Technical Alignment

Planning

Design

Executing

Development & Testing

Implementation

Operations & Maintenance

Evaluate

Architecture Assessment

Disposition

Closing


The graphic demonstrates that the various IT system processes align quite nicely, and that user seeking to stand up a new system or make major changes to existing systems can follow the basic 7 steps of the SDLC and complete the requirements of CPIC, EA, and PMBOK along the way (the touch points are all identified).

The way to read this graphic is as follows:

For example, in the first phase of the SDLC, the conceptual planning stage, the user does the following: 1) defines their need (SDLC process) 2) develop their business justification and seek to obtain approval and funding from the IT Investment Review Board (CPIC process) 3) develops their business alignment and seeks approval from the Enterprise Architecture Board (EA process), and 4) define their project and seek authorization to proceed (PMBOK process).

For CPIC, users identify the following:

  • Select—How does the investment meet business decision criteria?
  • Control—Is the investment being managed with the planned cost, schedule, and performance criteria?
  • Evaluate—Did the investment meet the promised performance goals?

For EA, users demonstrate the following:

  • Business Alignment—Does the investment support the agency mission?
  • Technical Alignment—Does the investment interoperate within the technology infrastructure and meet technical standards?
  • Architecture Assessment—Is there a need to update the architecture?

For PMBOK, users complete various project management processes:

  • Initiating—Define and authorize the project.
  • Planning—Define objectives and plan course of action.
  • Executing—Integrates resources to carry out project management plan.
  • Closing—Accept product or service.

Note: The EA/CPIC alignment is adapted from Architecture Alignment and Assessment Guide, Chief Information Officers Council, August 2001. The PMBOK definitions are adopted from the Project Management Book of Knowledge, Third Edition.

User-centric EA promotes the alignment of the various IT system processes to help users to easily understand the touch points in the various life cycle steps to getting their system up and running. Moreover, the alignment enables the CIO to develop processes and job aids to assist and ‘speed’ users through the process. Thus, the processes are transformed from inhibitors to facilitators of systems progress for the enterprise.

>EA and Principles of Communication & Design

>User-centric EA is about providing decision makers with not only the relevant information they need (i.e. current, accurate, and complete), but also serving it up in an easy to understand and readily accessible format.

To accomplish this, user-centric EA provides clear principles of communication and design. These include the following:

  • Focus on enhancing decision making
  • Develop useful and usable information products and governance services
  • Simplify complex information
  • Classify information into consumable chunks
  • Unify information by consolidating it and creating a common look and feel
  • Maximize use of information visualization (visuals, graphics, charts, and so on)
  • Provide accessibility through multiple robust delivery mechanisms (so users have the information when and where they need it)
  • Distinguish Enterprise from Segment and Solutions Architecture (to be discussed in a future blog)

By articulating and adhering to these EA principles of communication and design, you will greatly further your ability to deliver on the promise of user-centric EA.

Do you use similar principles of communication and design in building your EA?

>Is Strategy or Operations King?

>Strategy (read EA) and operations are two sides of the same coin — both ultimately seek to provide service and support to the end-user — and both are critical to making IT “work” as a functional whole.

In the Wall Street Journal, July 30, 2007, a number of prominent CIOs weigh in on the future of these two facets of IT.

Frank Modruson, the CIO of Accenture, predicts that within ten years, “you will see CIOs focus even more on strategy, whereas operations will be industrialized and outsourced…”

Similarly, Steve Squeri, the CIO of American Express, foresees that “the days of tech leaders as relationship managers and ‘order takers’ will go by the wayside… technical architecture will become a core function of IT departments.”

Both CIOs provide compelling visions of strategy and architecture playing an ever more central role in the enterprise for meeting business needs.

Do you agree with their visions? How important is EA in your organizations?

>How EA Benefits the Organization

>Even though user-centric EA benefits the user, the big winner is the enterprise. EA helps us functionally, as follows:

  • To plan better for IT refresh, recapitalization, and modernization
  • To make better investment decisions
  • To analyze problem areas and uncover gaps, redundancies, inefficiencies, and opportunities
  • To drive business process reengineering and improvement
  • To ensure information needs are met
  • To deliver technology solutions that meet requirements
  • To communicate, inculcate, and provide clear documentation about our enterprise

Technology-astute organizations know that user-centric EA is an elixir for much that ails their IT function.

Interested to hear from anyone on other organizational benefits…