2. Introduction
When discussing the familiar terms “agility / agile” we find that, regardless of the field of
inquiry or technical pursuit, expectations are synonymous with attributes used to describe a
high performance sports car: Agile is quick, Agile is responsive, or Agile is lightweight and
unburdened. These are often the expectations when Agility is discussed within the SE&I
community regardless of the context or level of abstraction within the lifecycle.
Haberfellner and de Weck provided insight into this dilemma, stating that there is a dis-
tinction between engineering Agile Systems and Agile Systems Engineering. At the SI, as we
began traversing the Agile landscape, in both our Customer engagements as well as our own
internal developments, we realized that we needed a deeper understanding regarding the
guidance on how Agility plays into Enterprise-level activities. We wanted Agility and Agile
themes to have meaning within our own culture, lexicon, and Enterprise; as such, we began an
undertaking to define Agility with respect to our SE&I Enterprise. As with endeavors such as
this, we welcome the reader to borrow from and add to in the spirit of advancing the art of
Systems Engineering.
Before addressing this proposition, let’s define what we mean by the term Enterprise:
“An entity comprised of one or more organizations, engaged in a singular mission re-
quiring the development, sustainment, and projection of supporting capabilities in a
changing environment.”
Thus, the dilemma for an Enterprise is how agility is achieved with all of the processes,
interoperability of organizations internal and external to the Enterprise coupled with overhead
planning, checks, and balances that make for a stable and successful business entity? Or, more
to the point, what does agility mean to an Enterprise?
The above description of an Enterprise as a business entity, at first blush, seems an unlikely
candidate for agile practices, principles or guidelines. A high performance sports car, for
example, is a system of interoperable systems, each with processes and rules of operations. But
what makes it “agile”? Agility, although scenario independent, requires context for the term to
have meaning. An Enterprise must be agile against something or in context of something, and
this comparison must make sense. I would like to propose that it is through the diligent process
of architecting and analyzing the business that agility can be properly evaluated, is achieved,
and delivered across and throughout an Enterprise.
Our business approach is to define Agility as it pertains to our Enterprise, and then de-
compose it for analysis. This allows Systems Engineers to understand the Enterprise, specifi-
cally the Enterprise Architectures and processes which define it. At the conclusion of this
paper, the reader will come to see that the defining characteristics that enable Enterprise agility
are twofold, and made of the following key contributors:
1). Enterprise Agility is the resultant of good Systems Engineering – manifested attributes
of a system which satisfies the mission needs in an ever changing and evolving environ-
ment with multiple levels of unknowns, and;
2). An Enterprise Culture that fosters open communication and pushes the power to act
upon and make decisions as the employee encounters change.
3. Defining Agility
Dr. Alberts of the Command and Control Research Program (CCRP) provides the fol-
lowing definition of agility:
“Agility is the capability to successfully cope with changes in circumstances.”
The robust nature of this definition is apparent. The ability to successfully cope with
change hinges upon many decision making capabilities upon which action can take place in a
temporal entity. This leads to Dr. Alberts’ notion of “timeliness”- as he further comments:.
“Agility does not require that one act as soon as they are able to act; rather it involves a
consideration of when would be the appropriate time to act.”
In an Enterprise context, what is timely for the survival of one entity may be rushed for
another, and too late for yet another. Removing the term rapid from the discussion of agility,
especially when outside the realm of rapid software development, establishes an understanding
upon which an Enterprise can act.
Still, there is fuzziness in the very nature of agility, even within Dr. Alberts’ robust defi-
nition, where concepts such as flexibility, resiliency, and innovation come into play.
At this juncture, we turn from the jargonized term “agile” to what it truly encompasses:
adaptability.
Adaptability
Leon C. Megginson of Louisiana State University made this interpretation regarding the
insights of Charles Darwin:
“It is not the strongest of the species that survives, nor the most intelligent, but rather the
one most adaptable to change.”
To this end, we explored this concept with the findings codified in Figure 1 below: “The
Enterprise Agility Equation”. Keeping up with the Environment’s rate of change results in
sustainment of the Enterprise. An Enterprise, in this context – business, that exceeds the En-
vironment’s change is in effect controlling the tempo of the business/market engagements, and
has therefore become a disruptor. .
Figure 1: The Enterprise Agility Equation
Similar to Dr. Alberts’ definition of agility, we find the temporal entity herein as well,
together with an even more concrete understanding of flexibility, resiliency and innovation. In
the Darwinian sense, these traits are attributed to the survivability of a species; for the sur-
vivability of any entity, especially a business, these traits are easily transferable.
Complexity of Change
The concepts complexity and change are tightly coupled with regard to discussions around
the implementation of Agility. Referring to Dr. Alberts’ definition, we see the importance of
understanding the circumstances through which we and or the System are experiencing change.
The challenges we face in an information age are the real-time interactions and depend-
4. encies across multiple disciplines throughout and across the globe. The interfaces between
connecting nodes are varied: some are hardwired, so to speak, with easy to predict and obvious
outcomes; others are dependent on other interactions between other entities whose interactions
are based upon the outcome of a completely different set of events and interfaces.
Figure 2: Inter-Dependent Networks
Figure 2 is a recreation of Dr. Alberts’ “Inter-Dependent Networks.” This representation
illustrates the complex nature of our real world activities. Although labeled “network,” A, B,
and C could be entities of any kind, one or all being biological, technical, entrepreneurial,
and/or political. Within each of these networks there are nodes providing a function, service, or
capability. Depending on the technical perspective, the single function of each node and rela-
tionship may in turn create capabilities upon which the other networks call upon for services.
The point is less about the specifics behind the terminology, but more about the relationships.
For example, Network A could be a financial institution with each node an in-
tra-organization providing functions, services, or capabilities upon which Network C, a logis-
tics company, draws from. Networks A and C are both internally connected as well as exter-
nally connected to one another with each connection presenting a potential point of failure (or
success) to varying degrees of criticality. More difficult to see in this representation, as well as
in our day-to-day lives are the dependencies between these networks, within each network, and
the nature of the exchanges between the networks. For example, the model is not capable of
answering questions like how are goods transported, how secure are the data transmissions,
what is the political climate in the country in which we are doing business and or dependent
upon materials for our own business success?
An Enterprise is faced with the challenge of prognostication over a large array of potential
what-ifs and could-be scenarios all with interdependencies on the various events, interfaces
and conditions. It is easy to predict the likelihood of a lit match going out when immersed in a
glass of water. The cause and effect is widely understood and has remained relatively un-
changed for millennia. What is not readily apparent is the multitude of touch points in our very
complex world in which we do business and the degrees of interdependency of an Enterprise’s
internal organizations. As noted in Hobart’s work, Kishido, regarding the Japanese technique
of indirect influence:
“One day the Master was explaining the way in which a small expenditure of energy early
on in a process could be equivalent to, or greater than a much larger effort at a later point…
a butterfly flaps its wings in China, and a week later, there is a storm in New York…
kochou-jutsu, the art of the butterfly.”
Complexity. Prior to now, this term was used without an adequate definition. Although we
have an instinctive sense of what complexity is, for the sake of accuracy and establishing a
common lexicon, this is the definition of complex from Merriam-Webster:
5. a). “A whole made up of complicated or interrelated parts and;
b). A group of obviously related units of which the degree and nature of the relationship is
imperfectly known.”
The second portion of the definition is particularly telling, as the challenge is often more
about gaining information for insight into these relationships that are “imperfectly known.” If,
for example, the National Oceanic and Atmospheric Administration (NOAA) knew which
types of butterflies, size, their weight, gender, wingspan, and under what conditions the beating
of said wings create the chain reactions that lead to the storms of kochou-jutsu, the activity of
these same butterflies would be factored into forecasting technologies.
Figure 3: Mothra
In the HBR article, “Want to Build Resilience? Kill the Complexity,” Andrew Zolli re-
counts the 2009 crash of Air France Flight 447:
“Yet it was complexity, as much as any factor, which doomed Flight 447. Prior the crash,
the plane had flown through a series of storms, causing a buildup of ice that disabled several of
its airspeed sensors — a moderate, but not catastrophic failure. As a safety precaution, the
autopilot automatically disengaged, returning control to the human pilots, while flashing them
a cryptic "invalid data" alert that revealed little about the underlying problem. Confronting this
ambiguity, the pilots appear to have reverted to rote training procedures that likely made the
situation worse: they banked into a climb designed to avoid further danger, which also slowed
the plane's airspeed and sent it into a stall.”
Zolli notes the triggering event of the horrific accident, a build-up of ice that disabled
airspeed sensors, is not in and of itself a catastrophic failure. Looking at this tragedy from the
O-O-D-A perspective, the failure of the sensors greatly diminished the ability for the pilots to
Observe, removing their ability to Orient, Decide and Act in a meaningful fashion. Also, as
noted by Hobart and (sadly) demonstrated by Air France Flight 447, this seemingly small seed
assisted in the development of conditions through which interactions may have a rather large
impact as we traverse the System.
The Systems, Enterprises, Organizations, and many of our day-to-day activities and en-
deavors rely on and are pieces of complex systems or, at the very least, interactions where the
sheer number of inputs and output of these interactions cloud the accuracy of the nature of the
relationships; we find casual misinterpreted as causal. This is true for both Entities and any of
their Relationships.
Change is a concept that is organic in nature. We all know change when we experience it;
the challenge for many of us is to accurately identify the degree of change while change is
taking place. Drawing upon Merriam-Webster once again, we find the following definition for
change, that we will use as the backdrop within this discussion:
6. a). To make different in some particular : alter;
b). To make radically different : transform
c). To give a different position, course, or direction”
It is the ability to notice change that is most important, and brings us to John Boyd and his
Observe, Orient, Decide and Act (O-O-D-A) loop.
John Boyd of the US Air Force revolutionized traditional command and control doctrine in
the 1970s with a C2 process model that accurately captures what we innately understand and do
regardless of our endeavor: Observe, Orient, Decide, and Act. For the purposes of this dis-
cussion, a simplified version of Boyd’s O-O-D-A loop is recreated below:
Figure 4: Simplified O-O-D-A Loop
John Boyd initially became aware of the O-O-D-A loop during his time in theater as a
fighter pilot for the US Air Force. Observing that an enemy fighter was on his “six,” Boyd
would maneuver his F4 Phantom in such a way to avoid being shot down, and depending on the
range, he would employ air-to-air missiles or use the aircraft’s guns to take down the enemy
fighter. We can imagine Boyd in the scenario above: making an observation, orienting his
aircraft accordingly, deciding the best tactic/weapon to employ, and finally, acting. What is
critical here is not the aircrafts involved, their performance specifications, nor the abilities of
the pilot (not to take anything away from Captain Boyd), but the concept that Boyd was able to
perform the O-O-D-A loop faster than his opponent..
In accordance to Boyd’s analysis of his personal C2 process, Dr. Alberts provides the
following commentary on the O-O-D-A loop:
“where better observations (improved quality of information) leads to better awareness of
the situation (orientation), which in turn leads to better decisions and more effective ac-
tions.”
How then does an Enterprise improve the quality of the information regarding itself and its
interconnections and processes to have better situational awareness, leading to better informed
decisions and actions, all within a timely fashion? The answer is twofold:
1). A detailed (Enterprise level) architecture and
2). An accompanying understanding of the processes therein
7. Enterprise Architecture
One challenge faced across the Systems Engineering landscape is defining what architec-
ture is, and subsequently, the Return on Investment (ROI) an Enterprise receives through its
architects and architectures. ISO 42010 defines architecture as:
“The fundamental organization of a system, embodied in its components, their relation-
ships to each other and the environment, and the principles governing its design and evo-
lution.”
Herein we find notes of the Enterprise: the multifaceted and multidisciplinary organiza-
tions that create the Enterprise, and more importantly, hints of the nature of the interconnect-
edness of these organizations through the governing principles in the design and evolution of
the Enterprise. This definition also hints to the concept that the Enterprise is a living entity,
evolving (adapting) to remain successful in its particular environment, similar to a biological
system or entity.
An architecture representing an information system or enterprise is often captured picto-
rially. The symbols making up the graphic provide high-level information that a user, systems
engineer and or a decision maker can use to better evaluate options as the System or Enterprise
evolves. The drafting portion of the development of an architecture view relies heavily on
knowledge of the system depicted. The data, processes, and interactions between and within
the entities all require intimate knowledge of or access to the information. These concepts echo
The Open Group’s description of architecture:
1). “A formal description of a system, or a detailed plan of the system at component level
to guide its implementation;
2). The structure of components, their inter-relationships, and the principles and guidelines
governing their design and evolution over time.”
The architecture provides a robust description of the System or Enterprise, stored in a
central repository. Behind each symbol, there are thousands of words, referenced documents,
and data providing the specifics of every detail that went into the design and building of the
system. Moreover, the processes, interactions, and order of events are documented in the
metadata behind the architecture view so as to enhance data analytics, thus assisting in the
evolution of the Enterprise.
The architecture described above provides value when organized in a consistent, repeatable
fashion. Furthermore, the architecture should be developed in an environment (tool) where the
objects and symbols in each view can be the results of a (relational database) query or per-
formance calculation1
. Architectures developed in this fashion create the baseline against
which the O-O-D-A loop is performed at the Enterprise level.
Frameworks such as DoDAF and TOGAF2
, for example, provide a range of architecture
1
These are concerns for large-scale information systems development and integration efforts. Generally with
these types of engagements, a style guide, working group, and review board are set in place by the Program’s
architecture leadership to ensure the products developed not only have the same look and feel visually, but
more importantly, are developed with the same type of metadata structure so as to ensure the calculation of
value of the architecture
2
Department of Defense Architecture Framework and The Open Group Architecture Framework, respectively.
8. views through which specific attributes of a system or service can be analyzed. The state of the
Enterprise becomes observable and, depending on the framework in which it is developed,
multiple vantage points provide highlights of specific System traits. For example, the DoDAF
Systems Interface Description, SV-1, documents the entities with which a specific System
interfaces. This provides awareness of the nodal activities and networks an Enterprise consists
of, interacts with, is dependent upon, and/ or provides services for. In this sense, the com-
plexities of the Enterprise’s interconnected nature become observable.
Architecture itself is a point of orientation. It allows the decision maker to observe from a
specific vantage point – to orient him or herself within a known entity from which complexities
of the unknown can be mitigated. Continuing with the example of an architecture artifact, the
applicable views within the DoDAF construct are orientation specific. DoDAF “Systems
Views,” for example, are System-centric. This is to say that regardless of the number of entities
and interfaces that comprise an SV-01, there is a specific System [A] against which the model
is created. This System [A], then, is the focal point of that particular architecture. At the En-
terprise level, these architectural views provide the ability for leaders to conduct analysis into
the portfolio of capabilities and services the Enterprise offers; providing insight into the ori-
entation of the Enterprise with regards to its position3
in its environment, as well as its ability to
perform its [business] mission against expected and unexpected conditions. This is especially
valuable when planning evolutionary activities or when a known interconnected organization
is not going to be able to fulfill its business mission requirements, thus leading us through the
loop and into the decision process.
As noted in Figure 1, the successful Enterprise evolves its Capabilities at a rate of change
faster than that of the change of its environment. Recognizing that change is constant, the
Enterprise must decide what actions are favorable for [business] mission success. The leaders
of an Enterprise must make informed decisions based upon the data gleaned from the archi-
tectures developed. Contingency planning, for example, includes decisions made regarding
logistics, supplier notification, and a multitude of other touch points that become known
through the information provided in the context of the architecture. These decisions are often
captured in the form of a plan, against which, action is taken, taking us to the final phase
through the O-O-D-A loop.
The previous stages of the O-O-D-A loop (observe, orient, decide), when properly docu-
mented, provide the plan against which focused action can be taken to ensure a successful
outcome as the Enterprise seeks to change its Capabilities faster than the environment changes.
Architecturally speaking, this plan provides actionable steps outlined to bring the Enterprise
from its current “As-Is” state to the desired “To-Be” state. When properly leveraged, these
architectures are more akin to actionable operating models as opposed to the static, schematic
architectures they are often compared to.
With the understanding that (Enterprise) agility is an amalgam of appropriate decisions and
actions with regard to the change of an environment and the Enterprise’s ability to adapt, it is
no wonder that Dr. Jeanne W. Ross is a champion for Enterprise architectures. In the briefing
“Gaining Competitive Advantage from Enterprise Architecture” delivered at the Weatherhead
School of Management, Dr. Ross explains:
“Architecture, the use of existing IT and business process capabilities to rapidly generate
3
Physical location in the spacetime continuum as well relative ranking when compared to competitors, cohorts
and colleagues
9. new business values while limiting costs and risks, allows for Agility.”
The value of the architecture lies within the understanding gleaned from the relationships
represented, and how these relationships can be leveraged to help the Enterprise succeed in its
mission and continuity of operations, as impacts to the interconnected nodes take place; it also
provides the situational awareness of risks to mitigate and disrupt as appropriate.
Agile Processes
Process is the backbone of many Enterprise activities. More often than not, to achieve a
desired goal or effect, there are steps – often sequential, in order for the achievement of suc-
cess. Instruction manuals and training materials of all kinds are step by step guides to the
process of the activity and undertaking thereof. Therefore these processes are often enforced
with rigor and discipline. Even in the realm of the mundane, we find processes involved in the
simple act of making a peanut butter and jelly sandwich. Although it is “common sense,” you
must first have the bread prior to spreading the peanut butter or jelly; further still, it helps to
have the required ingredients on hand. Even our human biology is a system of interconnected
systems each with their own processes.
The INCOSE Systems Engineering Handbook v. 3.2.1 borrows from ISO 9000:2000 in
defining the term process:
“Set of interrelated or interacting activities which transforms inputs into outputs.”
Keeping in mind the interconnected and multifaceted interactions and dependencies as
depicted in Figure 2, we see how important the activity of process documentation is, and how
this too falls within the boundaries and value of Enterprise architecture. Without knowledge of
the processes required of each node to achieve its business mission goals, and how these nodes
are interconnected and the dependencies, it is extremely difficult to become fully oriented to
the changes taking place in theater, as the degree of change and impacts thereof cannot be
properly assessed. Moving forward in this context is like “flying blind.”
Every step within a process within an Enterprise must be evaluated to make sure it adds
value and helps the Enterprise achieve its mission. Some steps are critical, while others are less
important, depending on the task, Customer, and planned use of the product and or services
delivered. For example, an IT system deployed locally versus the traditional monolithic satel-
lite used by NOAA requires a much different levels of reliability and availability. A hardware
failure on my company provided laptop requires a walk to the IT department on campus; a
hardware failure to one of the polar-orbiting environmental satellites (POES) requires a trip
into outer space. Time, money, availability of resources and the like come into play when de-
termining not only the specialty reengineering discipline of the “ilities,” but also as to how the
Systems are designed, developed, and the processes used. The idea then, is not just to cut
corners, but to know through experience and expertise, when tailoring a process is acceptable,
and what steps can be abbreviated or removed completely.
The ability to determine the value added by the processes within an Enterprise is the focus
of Lean Six Sigma activities, which ultimately serve to push the Enterprise through the
O-O-D-A loop with greater efficiency. The identification and removal of wasteful steps within
Enterprise processes that have evolved over time that have not been in lockstep with the
changes of the Environment in relation to the individual process which combine to create the
overarching processes of the Enterprise and said effects on total system objective is an act of
adaptation and thus, agility.
10. The INCOSE Systems Engineering Handbook v. 3.2.1 provides the following definition
and guidance regarding tailoring:
“The manner in which any selected issue is addressed in a particular project. The organi-
zation may seek to minimize the time and efforts it takes to satisfy an identified need
consistent with common sense, sound business management practice, applicable laws and
regulations, and the time sensitive nature of the requirement itself. Tailoring may be ap-
plied to various aspects of the project, including project documentation, processes and
activities performed in each life‐cycle stage, the time and scope of reviews, analysis, and
decision‐making consistent with all applicable statutory requirements.”
Tailoring a process or the activities within a process can save time, energy, and money;
also, it must be consistent with common sense. Someone who is not intimately familiar with the
product being developed, the in- theater uses and challenges, will not have the expertise to
determine which activities and processes must be followed and which processes and activities
can be tailored. The same is true with the development, evolution, and adaptation of an En-
terprise. Without expertise gained from experience within the Enterprise or environment in
question, the guidance of leadership is once again “flying blind.” Although the roadmap pro-
vided by an information-rich and well-documented architecture can help mitigate this short-
coming, the combination of intimate knowledge of the Enterprise, its operating environment
and an information rich architecture is a recipe for success. The actions of said Enterprise begin
to take on the properties of Agile as noted in the introduction. These successful companies are
the innovative and adaptive corporate entities that are continuously self-tailoring with respect
to their environment. This continuous cycle of change, as noted by Dove, is the backdrop of the
cycle and the market dynamics, which results in a never ending O-O-D-A loop (Figure 4) with
respect to the speed of change (Figure 1).
The Culture of Agility
A large contributing factor in the [amount of] agility within an Enterprise is its culture.
Although Organizational Behavior plays a large role in Agile themes, Organizational Behavior
is a theme much too vast for the confines of this paper. Still, this effort would be remiss without
touching on this topic at a minimum, especially with regards to employee empowerment.
The architecture of an Enterprise is not limited to its information technologies. A key
component in any successful business is its human capital, how they are organized, interact,
and are managed through leadership.
In “The 21st
Century Manufacturing Enterprise Strategy,” author Rick Dove addresses this
aspect of the Enterprise: “These systems must be structured to allow decisions at the point of
knowledge, to encourage the flow of information, to foster concurrent cooperative activity, and
to localize the side-effects of sub-system change.” Members of the business must be empow-
ered so as to actively participate in the O-O-D-A loop as they encounter change. A leadership
style that fosters information exchanges through open communication will uncover opportu-
nities to refine its processes, removing inefficiencies and increasing its rate of change as it
adapts to the Environment. Dove continues:
“Whether decisions are made by people or programmed machines one thing is true, they
can only be made quickly and accurately if they are made at the point of maximum in-
formation. Consequently, where people are involved, truly agile enterprises will push most
of the decision making process down to the lowest employee ranks, where the work is
actually done.”
11. In traditional military Command and Control (C2) Enterprises, the concept of empowering
those on the front lines of the engagement to make decisions instead of having to report back to
someone in higher rank for orders, is referred to pushing “power to the edge.” This concept is
very similar to that as noted by Dove.
As described by Alberts & Hayes in Power to the Edge:
“Edge organizations are, in fact, collaborative organizations that are inclusive, as opposed
to hierarchies that are authoritarian and exclusive. In socio-economical terms, hierarchies
are socialist and edge organizations are marketplaces. Edge organizations are organizations
where everyone is empowered by information and has the freedom to do what makes
sense.”
At first blush, this may seem somewhat Utopian, and slightly impractical. There are cer-
tainly some roadblocks ahead of each Enterprise, and our current business environment inhibits
an entire workforce from having access to all of the information required to make the “right”
decision. Coupled with costs in developing skills in areas and training associated with the
progression of the field, many Enterprises may find themselves financially burdened. Fur-
thermore, many Enterprises are organized and operated from the traditional hierarchical C2
structure and chain of command. Optimistically speaking, it may not be the fear of losing
power that keeps management from fostering a culture towards being that of the described
“edge organization,” but instead: “the road to destruction is paved with the path of good in-
tentions.” Without insight into the Enterprise strategic plan and details behind financial con-
cerns, an employee encountering a challenge may make what s/he believes to be the right de-
cision, but may in turn prove very costly for the Enterprise – something that leadership would
certainly prefer to avoid, mitigate or appropriately lead using their greater awareness of the
Enterprise’s situation.
And although this is somewhat of a worst-case scenario, true agility is scenario inde-
pendent – agility being the ability of the Enterprise to respond to the rate of change of its En-
vironment and adapt to the new Environment accordingly. Furthermore, the role of leadership
in an “edge organization” shifts from being that of Control to that of Guidance, as noted by
Alberts & Hayes: “Instead of being in control, the enterprise creates the conditions that are
likely to give rise to the behaviors that are desired.” These conditions are the processes and
architectures that align with the command intent of the Enterprise. The need and nature of each
task is articulated along with the goal behind each process and job description – all of which
flows from the Mission statement down to the lowest employee ranks.
Even with the latest information technologies, robust architectures and a well informed and
dedicated workforce, unless an Enterprise employs the mindset where the decision making
process is pushed down to the lowest employee ranks thus creating an edge organization, its
ability to respond and adapt to an environmental change will suffer. This is a critical piece in
the Agile Enterprise structure.
12. Conclusion
The goal of this paper was to help shed light on Agility in context to businesses, especially
those Enterprises engaged in Systems Engineering and Integration efforts. Having defined and
decomposed the constituent attributes that enable Agility, we find that when applied to the
Enterprise, Agility is a reflection of the interplay between the Enterprise (its architectures,
process and people), and its operating Environment.
To that end, we hope the reader will agree that the defining characteristics of Enterprise
Agility are twofold, and made up of the following key contributors:
1). Enterprise Agility is the resultant of good Systems Engineering – manifested attributes
of a system which satisfies the mission needs in an ever changing and evolving environ-
ment with multiple levels of unknowns, and;
2). An Enterprise Culture that fosters open communication and pushes the power to act
upon and make decisions as the employee encounters change.
It is through the combination of good systems engineering and an Enterprise culture whose
leadership empowers its workforce to make decisions that the fullness of Agility is realized. It
is this author’s humble opinion that Enterprises that operate in such fashions will always be
leaders in their fields regardless of their respective markets or domains: Agility is scenario
independent.
13. Acknowledgments
The author would like to thank the following individuals who contributed resources and
knowledge to advance the concepts put forth in this white paper:
1). Fisk, Charles L., The SI Organization, Inc.
2). Harris, Pritchett A., The SI Organization, Inc.
3). Janosko, Jodi, A., The SI Organization Inc.
4). Oliver, Deborah, G., The SI Organization Inc.
14. Biography
Don E. Brown II has worked in the Systems Engineering and Integration fields for the past
14 years. He started working as a technical writer and gradually became more engaged in ho-
listic Systems Engineering execution, specializing in architecture development. He graduated
from Bucknell University in June 1997 with a bachelor’s degree in Philosophy before gradu-
ating from Pennsylvania State University in December 2006 with a master’s degree in Infor-
mation Sciences.
15. References
Alberts, David S. 2011 The Agility Advantage. Washington D.C. (US): DoD CCRP
Alberts, David S. & Hayes, Richard E. 2003 Power to the Edge. Washington D.C. (US): DoD CCRP
Bachmann, Nord, & Ozkaya. 2012. “Architectural Tactic to Support Rapid and Agile Stability”. Cross-
Talk, May/June 2012
Coram, Robert. 2002. Boyd: The Fighter Pilot who Changed the Art of War. New York (US): Back Bay
Books
Dove, Rick. 1992. “What Is All This Talk About Agility?”. Bethlehem, PA (US): Agility Forum.
Dove, Rick & Turkington, Gary. “Relating Agile Development to Agile Operations”. 2008. Conference
on Systems Engineering Research (CSER), University of Southern California, Redondo Beach
Einstein, Albert. 1916. “Relativity: The Special and General Theory”. Methuen & Co Ltd.
Fairbanks, George. 2010. “Just Enough Architecture: The Risk Driven Model”. CrossTalk, Novem-
ber/December 2010.
Gothelf, Jeff. 2012. “How We Finally Made Agile Development Work”. HBR Blog Network.
http://blogs.hbr.org/cs/2012/10/how_we_finally_made_agile_development_work.html
Harris, Pritchett. 2013. “A Framework and Metrics for addressing an agile Enterprise”. Submission for
INCOSE IS2013.
Haskins, C., ed. 2011. Systems Engineering Handbook: A Guide for System Life Cycle Processes and
Activities. Version 3.2.1. Revised by K. Forsberg and M. Krueger. San Diego, CA (US): INCOSE.
Hobart, Peter. 2003. Kishido: The Way of the Western Warrior. Prescott, AZ (US): Hohm Press
Haberfellner and de Weck. 2005. “Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering”.
Fifteenth Annual International Symposium of the International Council On Systems Engi-
neering (INCOSE) 10 July to 15 July 2005.
Jackson, Michelle Bowles. 2012. “Step by Step” http://ianbutterfield.co.uk/wordpress/?p=297
Kennedy & Umphress Ph.D. 2011. “An Agile Systems Engineering Process”. CrossTalk May/June
2011.
Lapham, Mary Ann. 2012. “DoD Agile Adoption: Necessary Considerations, Concerns, and Changes”.
CrossTalk, January/February 2012.
Ross, Jeanee. 2011. “Gaining Competitive Advantage from Enterprise Architecture”.
http://www.youtube.com/watch?v=ScHG63YmJ2k
Ross, Well, & Robertson.2006. Enterprise Architectures as Strategy. Boston, MA (US): Harvard Busi-
ness Press
The Open Group. http://www.opengroup.org/
Toho-Towa Company, LTD. 1961. “Mothra”.
Zolli, Andrew. 2012. “Want to Build Resilience? Kill the Complexity”. HBR Blog Network.
http://blogs.hbr.org/cs/2012/09/want_to_build_resilience_kill_the_complexity.html
