Leon Kappelman, Ph.D.Professor of Information SystemsProfessor of Information Systems

Director Emeritus, Information Systems Research CenterDirector Emeritus, Information Systems Research CenterF ll T C t f Di it l K l dF ll T C t f Di it l K l dFellow, Texas Center for Digital KnowledgeFellow, Texas Center for Digital Knowledge

Information Technology & Decision Sciences DepartmentInformation Technology & Decision Sciences DepartmentCollege of Business, University of North TexasCollege of Business, University of North Texasg , yg , y

Founding Chair, Society for Information Management’s Enterprise Architecture Working GroupFounding Chair, Society for Information Management’s Enterprise Architecture Working GroupEmail: kapp@unt.edu Phone: 940-565-4698

http://www cob unt edu/profiles/112http://www.cob.unt.edu/profiles/112

25th Annual ASEE Conference 21-Feb-2015 Dallas 1

v20cFeb15

Getting AND Keeping Business IT Alignment Game plan (& Table of Contents)

Getting AND Keeping Business-IT Alignment Game plan (& Table of Contents)• The “Problem” of IT Alignment with the Business• What is the Essence of the Problem?• Research results from SIM Enterprise• Research results from SIM Enterprise

Architecture Working Group – (SIMEAWG)I Y Abilit t G t d St Ali d• Improve Your Ability to Get and Stay Aligned

• Questions? Discussion?• Appendices

• All of the Top 10 (maybe not #2) are business concerns first, IT second.business concerns first, IT second.• Nearly all are about the alignment of IT with the business.

The Problem of AlignmentThe Problem of Alignment

Alignment of IT with the Business consistently at

gg

Alignment of IT with the Business consistently at the top of the list of IT executives’ key concerns:

Oth i iti t h l i i do Other priorities, technologies, issues come and go

o For almost four decades “practitioners, academics, consultants and research organizations have identified attaining alignment between IT and businesses as a pervasive problem” (Luftman & Kempaiah MISQEpervasive problem (Luftman & Kempaiah, MISQE,2007)

Alignment is two part problem: Getting aligned ando Alignment is two-part problem: Getting aligned and Staying aligned.

Business leaders less sanguine than CIOs

6http://www.techproresearch.com/article/research-33-report-cio-role-is-losing-relevance/

The Problem of AlignmentThe Problem of Alignment

Business executives are quite dissatisfiedwith IT’s contribution to the business. • A 2014 survey of 3500 executives by Forrester found “a majority of businessA 2014 survey of 3500 executives by Forrester found a majority of business leaders think that their IT departments are more of a burden than a help.”CIOs are considered gatekeepers; not innovators or helping with driving new business for the company. “The criticism of IT was nearly p y yunanimous” http://formtek.com/blog/it-business-cios-get-no-respect/ ;

• “Only about a quarter [of CFOs] said their IT department ‘has the organizational and technical flexibility to respond to changing businessorganizational and technical flexibility to respond to changing business priorities,’ or ‘is able to deliver against the enterprise/business unit strategy’” http://www.itbusinessedge.com/cm/blogs/hall/survey-cio-cfo-relationship-still-prickly/?cs=47533;prickly/?cs=47533;

• “Almost half of CEOs … rate their CIOs negatively in terms of understanding the business and understanding how to apply IT in new ways to the business,” J. Stikeleather (2013) “The IT Conversation We Should Be Having,” HBR Blog Network, April 25, http://blogs.hbr.org/2013/04/corporate-it-and-the-conversat/.

Business leaders see CIOs quite poorly

8

CFOs see IT very negatively tooy g y

Wasteful, inefficient

Not aligned

N t t t iNot strategic

9

CEOs also see their CIOs negatively

What is the essence of the alignment problem? What is the essence of the alignment problem?

No matter how perfect the technology you deliver or how

g pg p

No matter how perfect the technology you deliver, or how well you managed the project, if you fail to build a system that actually meets the users’ requirements, then you fail.“The hardest single part of building a software system is

deciding precisely what to build. No other part of the g p y pconceptual work is as difficult…. No other part of the work so cripples the resulting system if done wrong. No

th t i diffi lt t tif l t Th tother part is more difficult to rectify later. The most important function that the software builder performs for the client is the iterative extraction and refinement of thethe client is the iterative extraction and refinement of the product requirements.” – Fred Brooks, 1987

“Delivering the wrong software is often worse thanDelivering the wrong software is often worse than delivering no software at all.” – Gerush, 2010

The Cost of an ErrorThe Cost of an Error (Hay, 2003)(Hay, 2003)ISDLC

KNOWING $1 StrategicPlanning

ISDLC

PLAN

REQUIREMENTS$5 Requirements

Analysis

Essence

READY, AIM$20 Design

$100 ConstructionDOING

BUILD & RUN

$500 Transition

BUILD & RUN

EXECUTION

FIRE!

Accident

$1000 Production

FIRE!

• Both are essential, but not sufficient alone.• Focus of SIMEAWG and this research is essence.

The Problem of AlignmentThe Problem of Alignment

Three issues are at the root of this problem:

gg

Three issues are at the root of this problem:1. Communicating effectively enough to partner with the business.

We call this “requirements gathering” or “requirements q g g qengineering”, but service-oriented professionals call this “knowing your customer and their needs.” Essence = Knowing

2 B ildi th IT l ti i h th t it i d t bl d2. Building the IT solution in such a way that it is adaptable and flexible enough to stay aligned with the ever-changing organization of which it is a part. This is the result of effective and holistic architecture and engineering. Accident = Doing

3. Performance measurement and incentives: People do what you inspect not what you expect Measuring the results affects theinspect, not what you expect. Measuring the results, affects the results. (“Hawthorne Effect” & “Heizenberg uncertainty principle”)

Requirements Capabilities FrameworkRequirements Capabilities Framework

Requirements ActivitiesRequirements Activities

RequirementsContext

Doing EA

U i SA&D

Using EABroad

Doing SA&D Using SA&D

E A id t

Narrow

Essence Accident

Two Types of Requirements Activities (RA)?Two Types of Requirements Activities (RA)?SIM EA Working Group StudySIM EA Working Group StudySIM EA Working Group StudySIM EA Working Group StudyWe separately measured both SA&D (narrow RA) & EA (broad RA)1. Systems Analysis & Design (SA&D) focuses on parts of organization:• Primary concern is optimizing a part of the enterprise, e.g., a specific software

system application organizational process activity function or divisionsystem, application, organizational process, activity, function, or division.• SA&D typically involves the application of software and hardware to the business.

2. Enterprise Architecture (EA) is concerned with whole organization:Primar concern is optimi ing the hole of the enterprise• Primary concern is optimizing the whole of the enterprise.

• How all the software systems, applications, hardware, and networks fit together.• How the IT assets and the rest of the organization work together interdependently.• An EA includes and serves as the holistic context for SA&D• An EA includes and serves as the holistic context for SA&D.

“If you are only trying to write a program, you don't need Enterprise Architecture.… However, if you are trying to create … an Enterprise, ... now you are going to have to have Architecture.”

– John A. Zachman (1997)

ISD capabilities improving, but more is neededISD capabilities improving, but more is neededp p gp p g

Latest survey conducted in Fall 2012 ISD (Information Services Development) Capabilities steadily

improving since 1996 [accident] Self Reported CMMI Maturity Levels Self-Reported CMMI Maturity Levels

90%100%

60%70%80%

Level 318.2% 19.6% 25.6%

30%40%50% Level 2

Level 1

0%10%20%

1996 2007 2012

See Appendices 1 and 2 at end for details

SA&D capabilities improving, but still fairly immatureSA&D capabilities improving, but still fairly immaturep p g yp p g y

SA&D capabilities improved since ‘07 [essence, narrow]

My organization’s requirements capabilities & practices … 2007 2012 PercentChange

are measured 2.99 3.00 0.3%

are benchmarked against other organizations 2.36 2.56 8.4%

are aligned with the organization’s objectives 3.90 4.01 2.8%

are highly disciplined 3.00 3.07 2.3%

are valued by non-IT leadership 3.34 3.58 7.2%

have non-IT leadership buy-in and support 3.57 3.37 -5.6%

are characterized by effective communication between 13 7%stakeholders and the requirements team 3.21 3.65 13.7%

describe our present ‘as-is’ or current environment 3.52 3.61 2.6%

describe our ‘to be’ or desired environment 3.60 3.64 1.1%

improve our ability to manage risk 3.61 3.75 3.9%

contribute directly to the goals and objectives of business plan 3.78 3.98 5.3%

are well prioritized by non-IT leadership 3.34 3.99 18.0%

h IT l d hi b i d 2 6%have IT leadership buy-in and support 4.18 4.29 2.6%

Overall Means (average of the question means) 3.42 3.58 4.7%

EA capabilities even less mature than SA&DEA capabilities even less mature than SA&Dpp

EA capabilities less mature than SA&D [essence, broad & narrow ]

My organizations requirements capabilities & practices … 2012 SA&D

2012EA

PercentDifference

are measured 3.00 2.61 14.94%are benchmarked against other organizations 2.56 2.38 7.56%are aligned with the organization’s objectives 4.01 3.53 13.60%are highly disciplined 3.07 2.73 12.45%g y pare valued by non-IT leadership 3.58 2.81 27.40%have non-IT leadership buy-in and support 3.37 3.01 11.96%are characterized by effective communication between ystakeholders and the requirements team 3.65 3.08 18.51%describe our present ‘as-is’ or current environment 3.61 3.33 8.41%describe our ‘to be’ or desired environment 3.64 3.29 10.64%improve our ability to manage risk 3.75 3.45 8.70%contribute directly to the goals & objectives of business plan 3.98 3.48 14.37%are well prioritized by non-IT leadership 3.99 2.62 52.29%have IT leadership buy-in and support 4.29 3.87 10.85%

Overall Means (average of the question means) 3.58 3.09 15.90%

Summary of Research FindingsSummary of Research Findingsy gy g• ISD capabilities slowly maturing (also see appendices at end).• Confirmed theory: Requirements = SA&D (narrow) + EA (broad).

• SA&D (to get aligned) and EA (to stay aligned) capabilities can be validly and separately (independently) measured this is huge!validly and separately (independently) measured – this is huge!

• Almost no use of performance measures for SA&D or EA activities – a sign that both requirements capabilities are immature. g q p

• Overall scores low too.• SA&D capabilities maturing, but still immature.p g,• SA&D capabilities more mature than EA capabilities.

• We’re better at accident (ISD) than essence (SA&D & EA).( ) ( )• We’re better at narrow (SA&D) than broad (EA).• EA capabilities are weakest of all.capab t es a e ea est o a

• Yet it’s key to the flexibility and adaptability of what we build/buy.• And thus it is key to staying aligned.

SA&D and EA are BOTH essential to increasing SA&D and EA are BOTH essential to increasing the likelihood of software success!the likelihood of software success!the likelihood of software success!the likelihood of software success!

Both SA&D and EA are BOTH essential to Both SA&D and EA are BOTH essential to increasing the likelihood of software success!increasing the likelihood of software success!increasing the likelihood of software success!increasing the likelihood of software success!

1 6% 6% 29 2% 6 3% 91 1%1.6% 7.6% 29.2% 67.3% 91.1%

1.6% 4.1% 10.0% 22.4% 42.8%

What Should You Do Now?What Should You Do Now?

Assess your capabilities. You’ve got the metrics now. Assess your capabilities. You ve got the metrics now. Build your strengths, strengthen your weakness.

• Improve SA&D & EA practices and capabilities.p p p• Be holistic: Learn from and incorporate the organization’s

stovepipes of SA&D- and EA-related knowledge (e.g., t t ti it l HR DRP b it ditstrategy, continuity plans, HR, DRPs, cybersecurity, audit,

policies & rules, data, etc.) into the requirements repository (i e the SA&D and EA knowledge base)(i.e., the SA&D and EA knowledge base)

Never forget that Internal IT is a not-for-profit services organization that should:organization that should:• Learn the business, become the business.• Help the value creators create value through

improvements and innovations

Bottom line Bottom line –– Remember this:Remember this:

Business-IT Alignment requires two parts:us ess g e t equ es t o pa ts1. Know the business & 2. Deliver the solution

1a Get Aligned (SA&D) 1b Stay Aligned (EA) 2 Deliver (ISD)1a. Get Aligned (SA&D), 1b. Stay Aligned (EA), 2. Deliver (ISD)

To achieve business-IT alignment you must:

• KNOW the business & its requirements (from strategy to tech minutia).

• DO – Design and deliver systems that meet the requirements d iland are agile (quickly and cost-effectively adaptable and flexible) .

• ADAPT – Change quickly and cheaply [depends on 1&2].• Keep knowing the requirements! The business is constantly changing so its • Keep knowing the requirements! The business is constantly changing, so its

requirements are too => Agile/adaptable requirements.• Adapt the systems accordingly => Agile/adaptable technology systems.

METRICS & INCENTIVES• METRICS & INCENTIVES matter a great deal – you get what you measure, you get what you pay for.

“No one has to change. gSurvival is optional.” p

– Dr. W. Edwards Deming

Thank You!Thank You!Q ti ?Questions?Discussion?Discussion?

Appendix 1Appendix 1pppp

Self-Reported CMMI Responses

CMMI L lSurvey Year

Self Reported CMMI Responses

CMMI Level 1996 2007 2012Level 1 (Initial/Chaotic) 50.5% 29.9% 24.4%

L l 2 (R t bl )Level 2 (Repeatable) 18.2% 38.1% 39.5%

Level 3 (Defined) 18.2% 19.6% 25.6%

Level 4 (Managed) 10 1% 11 3% 8 1%Level 4 (Managed) 10.1% 11.3% 8.1%

Level 5 (Optimizing) 3.0% 1.0% 2.3%

Total 2&3 36 4% 57 7% 65 1%Total 2&3 36.4% 57.7% 65.1%

Total 2,3,&4 46.5% 69.1% 73.3%

Total 2,3,4,&5 49.5% 70.1% 75.6%Total 2,3,4,&5Total 3,4,&5 31.3% 32.0% 36.0%

Appendix 2Appendix 2ppppSpecific ISD capabilities generally improving too [accident]

S f C 200 & 2012Software Development Capabilities: 2007 & 2012 studies comparedFor software development and/or maintenance, our IS department specifies and uses a comprehensive 2007 2012

Change From Percent

Changeset of processes and/or procedures for … 2007 Change

establishing stakeholder agreement on requirements 3.83 3.97 0.14 3.7%identifying the training needs of IS professionals 3.42 3.29 -0.13 -3.8%establishing quality goals with stakeholders 3 55 3 71 0 16 4 5%establishing quality goals with stakeholders 3.55 3.71 0.16 4.5%estimating all resource needs 3.55 3.76 0.21 5.9%tracking progress and resource use 3.82 3.83 0.01 0.3%software quality assurance 3.68 3.82 0.14 3.9%continuous process improvement 3.51 3.47 -0.04 -1.1%coordination and communication among stakeholders 3.90 4.02 0.12 3.1%selecting, contracting, tracking and reviewing software contractors/outsourcers 3.83 3.86 0.03 0.8%contractors/outsourcersanalyzing problems and preventing reoccurrence 3.75 3.72 -0.03 -0.8%tailoring the process to project specific needs 3.76 3.91 0.15 4.0%continuous productivity improvements 3.47 3.44 -0.03 -0.9%

Overall Means (mean of the means) 3.67 3.73 0.06 1.6%

What Should You Do Now?What Should You Do Now?

Design/build/buy for change – adaptability and agility• ‘SA&D’ is about describing the parts• ‘EA’ is about describing how all those parts fit together in an overall, enterprise-

wide context. If all you want is dis-integrated stovepipes, you don’t need EA.

Align requirements activities with business objectives• Know they will change: Design and build to accommodate change.

Ali i ti ith b i bj ti Align incentives with business objectives• On-time, on-budget, and high-quality but built to erroneous requirements does

not lead to alignment or help you stay aligned.Th d t h ll b d ith d i t If ilit d d t bilit• The road to hell may be paved with good requirements. If agility and adaptability and staying aligned matter, system requirements (SA&D) must be part of enterprise requirements (EA)

Is “alignment” still the right paradigm?• Might differentiating between IT and the business create a mis-alignment?• Are they really separable?y y p• Is the goal alignment or is it IT being one with the business, being the business?