Transcript Slide 1

Leon Kappelman, Ph.D.
Professor of Information Systems
Director Emeritus, Information Systems Research Center
Fellow, Texas Center for Digital Knowledge
Information Technology & Decision Sciences Department
College of Business, University of North Texas
Founding Chair, Society for Information Management’s Enterprise Architecture Working Group
Email: [email protected]
Phone: 940-565-4698
http://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)
• The “Problem” of IT Alignment with the Business
• What is the Essence of the Problem?
• Research results from SIM Enterprise
Architecture Working Group – (SIMEAWG)
• 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.
• Nearly all are about the alignment of
IT with the business.
The Problem of Alignment
Alignment of IT with the Business consistently at
the top of the list of IT executives’ key concerns:
o 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, MISQE,
2007)
o Alignment is two-part problem: Getting aligned and
Staying aligned.
Business leaders less sanguine than CIOs
6
http://www.techproresearch.com/article/research-33-report-cio-role-is-losing-relevance/
The Problem of Alignment
Business executives are quite dissatisfied
with IT’s contribution to the business.
• A 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
unanimous” 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 business
priorities,’ or ‘is able to deliver against the enterprise/business unit strategy’”
http://www.itbusinessedge.com/cm/blogs/hall/survey-cio-cfo-relationship-stillprickly/?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 too
Wasteful, inefficient
Not aligned
Not strategic
9
CEOs also see their CIOs negatively
What is the essence of the alignment problem?
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
conceptual work is as difficult…. No other part of the
work so cripples the resulting system if done wrong. No
other 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 the
product requirements.” – Fred Brooks, 1987
“Delivering the wrong software is often worse than
delivering no software at all.” – Gerush, 2010
The Cost of an Error
(Hay, 2003)
ISDLC
KNOWING
$1
PLAN
REQUIREMENTS
READY, AIM
DOING
Strategic
Planning
$5
Requirements
Analysis
$20
Design
$100
Construction
BUILD & RUN
EXECUTION
Essence
Accident
$500
Transition
$1000
Production
FIRE!
• Both are essential, but not sufficient alone.
• Focus of SIMEAWG and this research is essence.
The Problem of Alignment
 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
engineering”, but service-oriented professionals call this “knowing
your customer and their needs.” Essence = Knowing
2. 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 the
results. (“Hawthorne Effect” & “Heizenberg uncertainty principle”)
Requirements Capabilities Framework
Requirements Activities
Requirements
Context
Broad
Doing EA
Using EA
Narrow
Doing SA&D
Using SA&D
Essence
Accident
Two Types of Requirements Activities (RA)?
SIM EA Working Group Study
We 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 division.
• SA&D typically involves the application of software and hardware to the business.
2. Enterprise Architecture (EA) is concerned with whole organization:
•
•
•
•
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.


“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 needed
 Latest survey conducted in Fall 2012
 ISD (Information Services Development) Capabilities steadily
improving since 1996 [accident]
 Self-Reported CMMI Maturity Levels
100%
90%
80%
70%
18.2%
19.6%
25.6%
Level 3
60%
50%
Level 2
40%
Level 1
30%
20%
10%
0%
1996
2007
2012
See Appendices 1 and 2 at end for details
SA&D capabilities improving, but still fairly immature
SA&D capabilities improved since ‘07 [essence, narrow]
My organization’s requirements capabilities & practices …
2007
2012
Percent
Change
are measured
are benchmarked against other organizations
are aligned with the organization’s objectives
are highly disciplined
are valued by non-IT leadership
have non-IT leadership buy-in and support
are characterized by effective communication between
stakeholders and the requirements team
describe our present ‘as-is’ or current environment
describe our ‘to be’ or desired environment
improve our ability to manage risk
contribute directly to the goals and objectives of business plan
are well prioritized by non-IT leadership
have IT leadership buy-in and support
Overall Means (average of the question means)
2.99
3.00
0.3%
2.36
2.56
8.4%
3.90
4.01
2.8%
3.00
3.07
2.3%
3.34
3.58
7.2%
3.57
3.37
-5.6%
3.21
3.65
13.7%
3.52
3.61
2.6%
3.60
3.64
1.1%
3.61
3.75
3.9%
3.78
3.98
5.3%
3.34
3.99
18.0%
4.18
4.29
2.6%
3.42
3.58
4.7%
EA capabilities even less mature than SA&D
EA capabilities less mature than SA&D [essence, broad & narrow ]
My organizations requirements capabilities & practices …
2012
SA&D
2012
EA
Percent
Difference
are measured
are benchmarked against other organizations
are aligned with the organization’s objectives
are highly disciplined
are valued by non-IT leadership
have non-IT leadership buy-in and support
are characterized by effective communication between
stakeholders and the requirements team
describe our present ‘as-is’ or current environment
describe our ‘to be’ or desired environment
improve our ability to manage risk
contribute directly to the goals & objectives of business plan
are well prioritized by non-IT leadership
have IT leadership buy-in and support
Overall Means (average of the question means)
3.00
2.56
4.01
3.07
3.58
3.37
2.61
2.38
3.53
2.73
2.81
3.01
14.94%
7.56%
13.60%
12.45%
27.40%
11.96%
3.65
3.61
3.64
3.75
3.98
3.99
4.29
3.58
3.08
3.33
3.29
3.45
3.48
2.62
3.87
3.09
18.51%
8.41%
10.64%
8.70%
14.37%
52.29%
10.85%
15.90%
Summary of Research Findings
• 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!
• Almost no use of performance measures for SA&D or EA activities – a
sign that both requirements capabilities are immature.
• Overall scores low too.
• SA&D capabilities maturing, but still immature.
• 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.
• 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
the likelihood of software success!
Both SA&D and EA are BOTH essential to
increasing the likelihood of software success!
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?
 Assess your capabilities. You’ve got the metrics now.
 Build your strengths, strengthen your weakness.
• Improve SA&D & EA practices and capabilities.
• Be holistic: Learn from and incorporate the organization’s
stovepipes of SA&D- and EA-related knowledge (e.g.,
strategy, continuity plans, HR, DRPs, cybersecurity, audit,
policies & rules, data, etc.) into the requirements repository
(i.e., the SA&D and EA knowledge base)
 Never forget that Internal IT is a not-for-profit services
organization that should:
• Learn the business, become the business.
• Help the value creators create value through
improvements and innovations
Bottom line – Remember this:
Business-IT Alignment requires two parts:
1. Know the business & 2. Deliver the solution
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
•
and 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
requirements are too => Agile/adaptable requirements.
• Adapt the systems accordingly => Agile/adaptable technology systems.
• METRICS & INCENTIVES matter a great deal – you get what
you measure, you get what you pay for.
“No one has to change.
Survival is optional.”
– Dr. W. Edwards Deming
Thank You!
Questions?
Discussion?
Appendix 1
Self-Reported CMMI Responses
Survey Year
CMMI Level
1996
2007
2012
Level 1 (Initial/Chaotic)
50.5%
29.9%
24.4%
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 5 (Optimizing)
3.0%
1.0%
2.3%
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 3,4,&5
31.3%
32.0%
36.0%
Appendix 2
Specific ISD capabilities generally improving too [accident]
Software Development Capabilities: 2007 & 2012 studies compared
For software development and/or maintenance, our
IS department specifies and uses a comprehensive
set of processes and/or procedures for …
2007
2012
Change
From
2007
3.83
3.42
3.55
3.55
3.82
3.68
3.51
3.90
3.97
3.29
3.71
3.76
3.83
3.82
3.47
4.02
0.14
-0.13
0.16
0.21
0.01
0.14
-0.04
0.12
3.7%
-3.8%
4.5%
5.9%
0.3%
3.9%
-1.1%
3.1%
3.83
3.86
0.03
0.8%
3.75
3.76
3.47
3.72
3.91
3.44
-0.03
0.15
-0.03
-0.8%
4.0%
-0.9%
Overall Means (mean of the means) 3.67
3.73
0.06
1.6%
establishing stakeholder agreement on requirements
identifying the training needs of IS professionals
establishing quality goals with stakeholders
estimating all resource needs
tracking progress and resource use
software quality assurance
continuous process improvement
coordination and communication among stakeholders
selecting, contracting, tracking and reviewing software
contractors/outsourcers
analyzing problems and preventing reoccurrence
tailoring the process to project specific needs
continuous productivity improvements
Percent
Change
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, enterprisewide 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.
 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.
• 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?
• Is the goal alignment or is it IT being one with the business, being the business?