For over four decades, IT strategy has been about the alignment of technology with the needs of the “customer,” be it an organization, business, end user, or device. The most important part of system acquisition is deciding what to build or buy, as it is better to deliver no solution at all than it is to deliver the wrong solution. But there are two distinct dimensions to getting requirements and ensuring that they, and the IT solution that results, not only aligns with the business as it is, but is built in such a way that it can sustain that alignment in a cost-effective and time-efficient manner. Specifically, (1) narrow requirements, which focus on the short-term needs for specific parts, functions, or processes of the business; and, (2) broad requirements, which focus on a comprehensive, enterprise-wide approach with holistic and longer-range objectives like simplicity, suppleness, and total cost of ownership. We typically call these “Systems Analysis and Design” and “Enterprise Architecture” respectively. Ideally, organizations should be able to do both well, and effectively balance the inevitable tradeoffs between them. Sadly, in the vast majority of organizations, that is not yet the case. Professor Kappelman will present the results of a ground-breaking study from the Society for Information Management (SIM) Enterprise Architecture Working Group that developed and validated measures for these two distinct types of requirements capabilities. Findings include: • Empirical validation that there is, in fact, a difference between requirement capabilities in a narrow or individual system context (i.e., Systems Analysis and Design within the bounds of a specific development project), and requirements capabilities in a broad or enterprise context (i.e., Enterprise Architecture regarding how those individual systems fit together in an enterprise-wide strategic design). • Strong evidence that requirements capabilities overall are immature, with narrow activities more mature than the corresponding broad enterprise capabilities. • Solid evidence, based on fifteen years of studies, that software development capabilities are generally maturing, but are still fairly immature. This research provides requirements engineers, software designers, software developers, and other IT practitioners with tools to assess their own requirements engineering and software development capabilities. and compare them with those of their peers. Suggestions for improvements are made.

1. Leon Kappelman, Ph.D.
Professor of Information SystemsProfessor of Information Systems
Director Emeritus, Information Systems Research CenterDirector Emeritus, Information Systems Research Center
F 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 Department
College 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 Group
Email: 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

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

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

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

6. Business leaders less sanguine than CIOs
6
http://www.techproresearch.com/article/research-33-report-cio-role-is-losing-relevance/

7. The Problem of AlignmentThe 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 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 nearlyp y y
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 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/.

8. Business leaders see CIOs quite poorly
8

9. CFOs see IT very negatively tooy g y
Wasteful, inefficient
Not aligned
N t t t iNot strategic
9

10. CEOs also see their CIOs negatively

12. 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 theg p y p
conceptual 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

13. The Cost of an ErrorThe Cost of an Error (Hay, 2003)(Hay, 2003)
ISDLC
KNOWING
$1
Strategic
Planning
ISDLC
PLAN
REQUIREMENTS
$5
Requirements
Analysis
Essence
READY, AIM
$20 Design
$100 Construction
DOING
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.

14. 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 “requirementsq g g q
engineering”, 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”)

15. Requirements Capabilities FrameworkRequirements Capabilities Framework
Requirements ActivitiesRequirements Activities
Requirements
Context
Doing EA
U i SA&D
Using EABroad
Doing SA&D Using SA&D
E A id t
Narrow
Essence Accident

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

17. 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 3
18.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

18. 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
Percent
Change
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%

19. 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
2012
EA
Percent
Difference
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 p
are 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 betweeny
stakeholders 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%

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

21. SA&D and EA are BOTH essential to increasingSA&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!

22. Both SA&D and EA are BOTH essential toBoth 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%

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

24. Bottom lineBottom line –– Remember this:Remember this:
Business-IT Alignment requires two parts:us ess g e t equ es t o pa ts
1. 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.

25. “No one has to change.g
Survival is optional.”p
– Dr. W. Edwards Deming

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

27. Appendix 1Appendix 1pppp
Self-Reported CMMI Responses
CMMI L l
Survey Year
Self Reported CMMI Responses
CMMI Level 1996 2007 2012
Level 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,&5
Total 3,4,&5 31.3% 32.0% 36.0%

28. Appendix 2Appendix 2pppp
Specific ISD capabilities generally improving too [accident]
S f C 200 & 2012Software Development Capabilities: 2007 & 2012 studies compared
For software development and/or maintenance, our
IS department specifies and uses a comprehensive 2007 2012
Change
From
Percent
Change
set 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/outsourcers
analyzing 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%

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