The Agile Enterprise: Systems Engineering Agility at the Enterprise Level

2013 INCOSE Symposium

The Agile Enterprise: Systems Engineering Agility

at the Enterprise Level

Don E. Brown II, MSIS The SI Organization, Inc.

Don.E.Brown.II@thesiorg.com

The SI Organization, Inc. 720 Vandenburg Blvd.

King of Prussia, PA 19406

Copyright © 2013 by The SI Organization, Inc. Permission granted to INCOSE to publish and use.

Abstract. Agility is all the rage. Across the landscape, businesses request agility as a deliver-able, make claims that they are agile, and (some) go so far as to assert they can provide agil-ity to other corporate entities outside of their own sphere of influence. The challenge before us as a Systems Engineering Community is that (Enterprise) Agility, although well docu-mented throughout engineering literature since the early 1990s, is often misinterpreted. Agility means many things to many people, and heretofore, has been used as a synonym for rapid development and delivery. Although speed is a byproduct of agility, speed in and of itself is not robust enough to encompass all that agility provides an organization, its cus-tomers, and partners. The goals of this paper are to shed light on agility in context to busi-nesses, especially with Enterprises engaged in Systems Engineering, and provide guidance as to how agility is best achieved regardless of the Enterprise’s business or mission objectives.

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.

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-

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:

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:

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

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.

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

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.

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

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.

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.

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.

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.

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