Agility and the Virtual Extended Enterprise
In the 1990s, The Agility Forum of
Lehigh University defined Agility as "The ability to successfully respond to
unexpected challenges and opportunities." The
forum chartered a technical committee that created two documents.
The first defined the Virtual Extended Enterprise. A second, that
I co-authored was entitled The
Key Needs of the Virtual Extended Enterprise. As I
describe in my book, Organizational Economics: The
Formation of Wealth, a Virtual Extended
Enterprise (VEE) is a cross ownership domain organization whose
purpose/goal/mission is to create a particular product or service and to
support it through its life cycle. This means that a group of skilled
individuals and organizations band together to form an "enterprise"
whose mission is to create or innovate and design a product, produce it,
support it, and finally dispose of it.
In my book I predict that more of the
VEEs will come into existence within the "high-tech" industries
because consortia of small highly innovative organizations, loosely
coupled (in a legal sense), will be able to out adapt larger organizations,
that is, they will work inside the large organization's OODA loop. Col.
John Boyd, father of the OODA
loop, based its concept on taking effective action in
a time efficient manner. In the context of battle, this is
either hitting the enemy from an unexpected direction or at an unexpected time,
and so on, or counter-punching a strike by the enemy in the same manner--that
is, out thinking the enemy. To do this, they will need to use swarming
tactics.
Agility and Swarming Tactics
Swarming is "A method, procedure, or
process for meeting unexpected challenges and taking advantage of
opportunities"; sounds a lot like agility. A
swarming process has many organizational components "gang-up" on the
challenge or opportunity using various swarming tactics; some of which are
discussed in the examples in the following section. To some degree, swarming is already used
in "Silicon Valley" where individuals and very small firms can
organize, almost over lunch, to produce a new product. This is very much
a Service Oriented Architecture (SOA) model for business, where each part
of the organization is a "business service component", and the whole
is a "business composite enterprise". Still, this sounds like
nothing more than a more flexible version of the waterfall
(straightline) business and product life cycle model.
However, nature presents a more agile way
to "out-think" the enemy or meeting a new challenge of any type, swarming
tactics. Again, Swarming is "a large number of
animate or inanimate things massed together and usually in motion : throng
<swarms of sightseers> <a swarm of locusts> <a swarm of
meteors>." Normally, these "things" are apparently autonomous,
but acting, operating, or moving as if in concert or by some
"invisible hand". The key characteristic of all of these
examples is that the individual "things", self-directing components
are much smaller than their prey or opponent, yet as a team or organization
they overcome with ease. The agility comes from the different types of
(service) components, their assembly, and the tactics of their response.
Here are three well known examples.
Army Ants--Army Ants use at least two forms of
swarming in their exploitation of their environment. In fact their
"Missions" are "to provide food for the army" and
"protect their bivouac (nest)". This is true of all life.
However, the strategies and swarming tactics they use are different from the
"biggest animal with the most teeth, wins" strategy of most
animals. Instead, the ants search for prey either in somewhat parallel
columns or in a fan shape. When they come upon a prey, the first ants to
encounter it signal to others while immediately latching onto it. Then
additional ants join, swarming on the unfortunate prey. [Sidebar: This could include humans that are young
enough, silly enough, injured enough to not walk away from the
ant army. According to one article, up to 5 people a year are killed by
army ants.]
Antibodies--White blood cells and other
antibodies are the second example. Their mission is to defend the
body from invading microorganisms including viruses. They are on the
alert for anything that is not foreign to the body and when discovered swarm in on it. The antibodies are
agile in both that they have ability to sense, methods for swarming, and the
organization/tooling enable the methods. One of the reasons for the
effectiveness of flu shots (or vaccines) is that they introduce
"life-like" targets for the antibodies to practice on (the actual
microorganisms, but dead). This enables the antibodies to reconfigure or reorganize
themselves to sense the microorganisms and plan the swarming attack.
Consequently, when the body is attacked by a microorganism resembling the dead
microorganism in the shot, the antibodies execute the plan and, hopefully, the
microorganism.
Wolf Packs--Wolf packs are yet another organism
(animal) that uses swarming tactics to survive. Like the army ants, the
wolf pack has two missions; "to provide food for the army" and
"protect their bivouac (i.e., the den and the young and old)".
A single wolf, however large and ferocious, is not able to "take
down" even the weakest bull elk or moose by itself. However, wolves
have senses, intelligence, and communications skills that the ants may not
have. For example, they smell their prey herd at a significant distance;
they use a relay method to chase a herd until the weak cannot keep up; and they
then swarm the weak member using their combined fangs to overwhelm the larger
prey/opponent. On defense of their den they are equally as voracious.
Examples in the organizational
Environment
Strategies are used by organizations
to achieve their Mission(s) and Mission(s) are used the organization to achieve
its Vision. Strategies are the plans for achieving a goal (or Mission),
tactics are the patterns of attack whether it's another
organization or a problem or obstacle in the way of the achieving the Mission
and Vision. This is important for Enterprise Architects to remember.
One set of
organizational tactical patterns is the set swarming patterns. It is
one of the most sophisticated, complex, yet elegant patterns
when successfully executed. The risk is that it is agile, which is
both its strength and its weakness. Here are examples of each.
WWII US Army Task Groups and Task
Forces
In WWII, both the US Army and Navy
used reconfigurable units, and to some degree swarming tactics, to their
advantage. After WWI, that is in the 1920s and early 1930s, the cavalry
and the infantry each thought they knew the properly role for tanks, the
cavalry for exploiting breakthoughs (a typical mission of the cavalry), the
infantry to support the infantry on defense and in creating
breakthroughs. Consequently, the infantry wanted a slow moving tanks
(maximum speed of about 5 MPH) that was heavily armored. In contrast, the
cavalry wanted fast moving tanks, which meant that they would be much more
lightly armored.
In the two years that followed the
appointment of George C. Marshall as Chief of Staff of the US Army, he
transformed the upper echelons of that organization. Among the many
reforms, he created the Chief of Armor. Prior there was a armored
"cavalry" regiment at Camp (Fort) Knox and an armored
"infantry" regiment at Fort Benning. These had been organized
as "experimental" units in the late 1930s after Chief of Staff
MacArthur disbanded the early experimental units. However, under the
direction of General Edan Chaffee, the leading doctrinal theoretican and
architect of armor and previously in command at Fort Knox, the initial
functional design of the WWII Armored Division was constructed. [Sidebar: It
is interesting to note that a couple of the leading proponents of armor in Nazi
Germany were sent to Fort Knox to "observe" the experimental
regiment. When Germany attacked Poland, setting off WWII, they used most
of General Chaffee's architecture and doctrine in the attack, "the
Blitzkrieg".]
General Chaffee's architecture for the
armored division, the basic unit at the time, included tanks and infantry
regiments, with supporting artillery, engineering, and air units--in other
words, all of the elements of the US Army at the time. Consequently, the
Armored Division Commander could reconfigure the elements of the attack depending
on the mission and strategies employed. After maneuvers in 1940, the
Divisions were further architecturally refined to make them more agile, by
eliminating the brigade structure, and having the regiments report directly to
the division Commanding Officer (CO). Then they added task
group COs. The Division CO would assign units to the task group/force CO
depending on the mission and strategies to be employed.
However, it was not until the 3rd Army
under General Patton's command that the agility of the armored
divisions and the swarming tactics showed its full flower with
air/ground teams using units from armored and infantry brigaded together in
task forces. This is the well known and documented race through France in
August 1944. It is shown additionally by the 90 degree swing of the
3rd Army in the Battle of the Bulge. And finally, by the 1st Army's
ability to swarm the Ludendorf railroad bridge
across the Rhine at Remagen, creating a crossing where none had been
"planned" and exploiting it.
The Film-Making Industry
An example that I use in my book is of
the film industry. One well known example of this type of enterprise are
movie companies. They form to make a movie and dissolve once the final product
is on the market (for some movie franchises, this may be a fair number of
years). The movie company forms (and swarms) around a
movie script or concept. Once the movie is made the organized swarms dissolves
with each component off in search of new opportunities.
ABB
One project oriented organization,
ABB, one of the largest European corporation with about 125K
employees, is built on a Swarming Architectural Pattern. This
organization is known for its management structure, which has only five levels
(many organizations in the US with only 5000 employees have at least that many
or more). Yet, ABB makes money. They do it by having many different
engineering disciplines formed into relatively small teams. According to
Tom Peters, these teams are mostly self-directing/managing. If one team
finds an Request For Proposal (RFP) they cannot support or support in total,
that team networks with other teams in the corporation to create a proposal,
and if they win, to execute against that proposal. In other words, the
ABB team swarms on any RFP through the ABB
organizational network.
Tiger Teams
Many organizations use "Tiger
Teams" to rescue development and transformation programs and project that
are in cost and schedule difficulties (the Programmatic Requirements).
This may be because of unanticipated technical risks, management mishandling of
activities, or many other causes. A Tiger Team is a set of personnel that
are the best (most knowledgable) available to the organization. These
team members may be culled from all of the units of the organization or from
other organizations. One way to dispose of a risk is to transfer
it. [Sidebar: While most managers and financial engineers think the
mitigation is the only way to disposition a risk, there are three others,
including transference. See my post The
Risk Management Process] With a Tiger Team, the risk item (the unknown) is
transferred to someone who may know a solution or have a quick method for
determining a solution. The reason for having a Tiger Team is to swarm the design risk with the most
knowledgeable team to increase the probability for turning the unknown
into a known in a reasonable time and least expense, since any design risk may have more
than one method for turning the unknown into a known.
Inhibitors and Facilitators
From the examples, above, it is clear
that good systems engineering, system architecture, and enterprise architecture
are the only processes that will minimize the probability and impact
of the design risks in complex development based on pushing the edge of
technology, and especially for swarming processes and their enabling and
supporting systems and products.
Good enterprise architecture can model
the most effective investment opportunities based on the organization's
mission(s), its strategies, and its swarming tactics, while good systems
engineering can identify problems with requirements in the initial stages of
development (when changes are most cost efficient) and system architect can
create an architecture with non-redundant functions, grouped and structure in
the architecture, that when allocated reduce the risk of requiring non-standard
components and minimizes the effort and risk of development of the non-standard
components.
Inhibitors
There are many inhibitors to agility,
swarming tactics, and good supporting and enabling systems. Three of
these are described below.
Over Specification and Other
Requirements Problems
One inhibitor, as amply shown in the
example, is over specification of requirements and other problems with the
requirements. Over specifying requirements is one of several types of
requirements issues (see other posts in my blog for additional, as well as Dr.
Ralph Young's book on requirements); others being missing and
"just plain wrong" requirements. For example, I worked on an
enterprise portal for a major organization. When I joined the program, it
was already in serious trouble because the sales team had promise to have the
portal "fully functional" with 6 months and at half the cost that was
initially estimated. Unfortunately "fully functional" was not
defined nor were the customer requirements clearly and completely defined, so
the customer expected a portal of their wildest fantasies in 6 months.
This included corporate security who saw the portal effort as a way to get
control of all applications on the network.
Based on what had been promised, I
tried to put together a customer system requirements document only to find that
the security requirements (among others) were so over specified that it would
be infeasible to meet, and impossible in the timeframe. When I pointed
this out to the customer, and recommended a series of short cycles for
development--boiling a kettle at a time, instead of the ocean--my team was
replaced with a new team, which failed. After a series of catastrophic
project failure by several teams, the customer finally understood that not all
of the requirements could be met, or at least met in the time frame, they
finally had a working enterprise portal. It likely cost the customer 10
times as much as if the customer had followed my short cycle (agile
development) plan and took at least 5 times as long.
Two ideas should be taken from this
example. First, insistent over specification and other failures in
requirements management will inevitably lead to failure. Second,
attempting to use the waterfall development process and a highly managed
process with incomplete and/or over specified requirements greatly increases
the risk of project failure. A better way to do it is to use short cycle
development on large complex projects and programs. Further, in doing so,
swarming tactics could be used. For example, when I led a
process innovation project and concurrently managed an advance IT
laboratory at a major corporation, I would hold weekly staff meetings with a
team of 16 IT experts and up to 32 others. The meetings were as much
about design risk management as about weekly status for my role a program
manager. When a team member would bring up a risk or an issue, we would
have a brief discussion followed by a number of team members getting together
after the "status" meeting and coming to a solution. For the
team this was a swarming tactic; one that would not be
"allowed" in a control freak management culture.
"Transactional Management"
There are two types of management,
transactional and transformational. Transactional management is what most
people would define as "Management" or "Supervision".
This type of management creates "The Plan" and follows it regardless
of whether "The Plan" still makes sense. These are the Control
Freak Management and Cultures. They put following the plan ahead or
adapting to the changing environment. In development this type of
management is called transactional (waterfall program management) method for
development.
Working on a program where innovation
is one key goal or high-level requirement for the program, transactional
management will inevitably lead to cost and schedule overruns and most likely
project failure (unless the budget and schedule drastically increase). The
reason is that by definition innovation is the result of incorporating elements
of the technical unknown (called risks) into product.
The level of time and budget required
to convert and unknown into a known cannot be defined, only forecast; and as I
can attest, sometimes if turns out much simpler than forecast, but many times
even what appears to be a minor risk (a small can of worms), turns into a
research effort the equivalent of the entire effort. At this point the
transactional manager goes into freak mode, creating 16 levels in the Gantt
charts and holding program reviews every half day, in a futile effort to keep
the project meets the business requirements of cost and schedule.
Transactional management greatly
impedes swarming tactics, because swarming tactics require that the small
groups are semi-autonomous. That is, they are told what their objective is, but
not how to reach their objective. It is up to them to meet the objective
and to call on other teams with other skill sets as needed. This gives
control freak managers apoplexy because they have only a limited degree of
control.
Communications
Early in my corporate career I had a
boss who always said, "Communications is a Bitch", and it is. Words
and phrases have culturally connotative and well as denotative meanings; which
is one reason translation is so difficult. On technology projects they can be
even more so. One project on which I worked had a 300 page glossary of
acronyms, with one acronym that was used over 50 times with completely
different meanings depending on the engineering or manufacturing discipline.
Obviously, in the process of developing, constructing, or implementing a
new product, system, or service poor communications will cause a great deal of
process friction, which in turn adds to cost and time to a project to get
everyone speaking using the same terms [Sidebar:
I've termed this "violent agreement". Either having a long vehemently
intense discussion around using different terms to mean the same concept or
using the same terms to mean different concepts] and misunderstanding customer,
functional or component requirements and specifications leading to (potentially
catastrophic) product defects. I know of an internal unpublished
corporate study of several major development programs where 25 to 50 percent of
the typical engineer's time was spent in meetings to get clear requirements and
other sort out other engineering issues, while maybe 25 percent was spent on
the actual engineering. [Sidebar: the rest was
spent getting ready for program reviews, in the reviews, or getting feedback
from the reviews]
Communications issues can be
exacerbated when many small groups swarm on an issue for the same reasons that
a single team have issues, as stated above, except they may be several orders
of magnitude more difficult.
Facilitators
There are some facilitators of agility, swarming tactics, and good
supporting and enabling systems. Four of these are described below.
Standards
As weird as it sounds, having a clear and appropriate sets of
standards and policies is a key facilitator for agility and swarming tactics
for a project. But, this is if and only if the set is appropriate in what
the standards are for. Too many will kill off a project in a sea of intermediate
artifacts (reports, presentations, and other documents that have no purpose but
to meet some policy or standard). Too few will kill off a project slowly
by the need to reconcile interfaces, among components, assemblies, and
functions. This is a great facilitator of swarming tactics
In any software development process, I would suggest that the team
start with a minimum set of software interface and documentation standards.
Interface standards reduce issues with connecting modules, components,
etc. There are several such sets of standard for SOA. Software
documentation standards, including configuration management standards, greatly
reduce the time for defect analysis, and will greatly help future maintenance
and upgrades when the product is put into operation. In general, the
standards for hardware products and interfaces among components are well
defined.
Process Design and System Architecture Derivation
A second facilitator is the combination of process design and
functional derivation/functional design/system architecture. Obviously,
if the customer's "must do" requirements are poorly identified, no
amount of design work will create a product that will meet what the customer
really wants. [Sidebar:
As defined in the CARRMA(r) product I've developed, must
do or event
driven requirements
define the methods, procedures, and processes the product must support.]
Consequently, a well defined process is of seminal importance when using using
swarming tactics. The conundrum is that well defined methods, procedures, and
processes are not always possible, especially went including technical
innovations in the product, system, or service.
The derivation of clear, concise System Architecture or
specification, or of a functional design is exceedingly important because it
enables the program management to communicate the requirements of the
functions, assemblies, and components to the swarm of technical personnel.
Again, as the many research articles and documents, the many
methodologies and procedures, and the many program failures demonstrate
deriving clear and concise system architecture or functional design is nearly
impossible; another conundrum.
Short Cycles
One way, perhaps the only way, out of the conundrums, above, is
through the use of short cycles of design, development, and construction.
That is, plan for incomplete, fuzzy customer requirements at the start of
the project and an evolving system architecture/functional design. This
builds agility directly into the design/development/implementation process of
the project.
To do this, first, create a high-level notional design based on
the known customer requirements. With the customer, identify any defects
in this design and with the design/development team identify any unknowns
(risks). Second, build a prototype of the core of the application and
share it with the customer. Constructing this first prototype should take
about one month. The core should include the main interface with the
user(s) and the access control and/or safety function(s). I have found
that showing the customer this prototype will do two things, elicit wire
brushing from the customer for miss interpretation of the fuzzy requirements
the customer identified and much clearer and more complete requirements.
At the same time, start to prototype all unknowns in the system in
short monthly cycles. This is where the swarming tactics begin. The
initial build of the prototypes will demonstrate which unknowns will be easy to
make known and which won't.
After the first monthly cycle have the customer choose which of
the know set of requirement to implement first (prioritization of the
customer's requirements), then choose one or more to implement during the next
short cycle. At the same time continue to prototype the unknowns.
Demonstrate to the customer where a particular customer requirement is
leading to unknowns (risks) that will shortly create issues (technical, cost,
and/or scheduling problems). If there is a required function with a high
risk (very likely to occur) with a high impact on the effort, focus the
swarming on that unknown.
At the end of the second monthly cycle demonstrate the product to
the customer. I have found that after the second or third cycle (two to
three months) that the customer will deem the product the IOC (initial operating
capability) and want it put into production. In each short cycle you can
add functionality to the production system and with the customer, you may (and
most likely will) add to the customer's requirements list. This method
will greatly increase customer satisfaction.
Transformational management
To use swarming tactics requires a transformational management
style. A transformational management style means that the management
adapts the project to the changing customer requirements and priorities of the
requirements, the identification of unknowns (risks) and possibly the
introduction of new technology in the process of designing, developing,
constructing, and delivering a new (custom) product. This is in stark
contrast to the transactional management that cast the requirements and project
plan in concrete and allows for no deviation until the project fails.
Enter EA, SA, and SOA
At first blush, Agility, and System Architecture/Enterprise
Architecture seem to be diametrically opposed to one another; agility
requires flexibility while one characteristic of architecture is
rigidity. Yet, in fact, architecture is a method for structuring,
ordering, and organizing functions (a functional design) to meet the customer's
requirements. So what is an agile architecture that enables swarming
tactics? Enterprise Architecture provides the mission or goal,
the strategies, processes, procedures, and governance supporting early, clear, and complete
identification of the customer requirements for the project. System
Architecture provides the ordered and structured functions of the product supporting the design
to meet the customer's requirements.
VEE,
Swarming Tactics, and SOA
As defined and discussed in many of my prior posts, a VEE or
Virtual Extended Enterprise is a form of a supply chain. However, it is a
supply chain with differences. First, its not a parts ordering supply
chain. Instead all members of the VEE have a stake in the success of the
product. Second, its members all have peer-to-peer communications.
This means there is a coordinator of the activities in creating the
product rather than a top down command and control organization.
Ford: The Integrated Supply Chain
A typical supply chain has an Integrated Command and Control
Organization to support highly structured projects and use
"waterfall" transactional program management. Each organization
in the supply chain has a has a clearly defined position in the supply chain
with (hopefully) clear and complete contractual technical and business
requirements to meet in order to create the product. This of supply chain
organization performs quite well when technology is changing at a slow rate.
And it works particularly well for the reduction of manufacturing or
implementation costs, that is making the product more cost efficient. For
example, Henry Ford introduced the Model T to the American public in 1908.
It was the first cost efficient automobile that met, from the start, the
public's requirements for dependability.
The reason oft cited for Ford's and the Model T's success is the
assembly line, though it was really Fort's focus on a cost efficient supply
chain including the assembly line. Ford treated the entire supply chain
as a integrated command and control organization to the point that he built the
Ford River Rouge facility in Dearborn Michigan as nearly a complete supply
chain for the manufacturing of cars. The integrated manufacturing
facilities included docks to off load iron ore, a steel mill, a glass factory,
a rubber and tire plant, and most of the other facilities needed to turn raw
materials into an automobile. Now that's integration of the supply chain with a
capital I. For 19 years the Ford Motor Company manufactured the Model T
successfully. However, by 1927 other manufacturers were building cars in
the same price range but with functions the Model T did not possess. If I
remember right that included electric starting (also, the only color the Model
T came in was black). So by 1927, the customer's business requirements,
(cost), was superseded by the customer's increased technical requirements (new
functions). So, The Ford Motor Company had to design and manufacture a
competitive vehicle or go out of business; enter the Model A.
By the 1950s, technology was changing at a rate such that the auto
companies were coming out with a new design every year. [Sidebar: In many
cases it was more of a change in the surface sheet metal than a technology
change, but technology was trickling in during the 1950s, and was streaming in
by the 1960s.] However, the customer could still order and pay for a car
with just the functions (options) the customer desired well into the 1960s.
By the 1980s, the custom options had metamorphosed into options
packages. The reason was simple, the plethora of options, in an era of
paper, custom manufacturing of each vehicle very expensive and ended up many
defective vehicles; cars with the wrong options, which cost significantly more
to retrofit than if they had been built with the options to meet the customer's
requirements in the first place. Additionally, it reduced the number of
vehicle configurations from a very large to a more cost efficient number.
Consequently, the customers had to get used to paying for options they
didn't want to get the ones they wanted--a somewhat mixed blessing for the
customer. And this is where automobile manufacturing processes supporting
the customer's requirements stands at this point.
The members of the Integrated Supply Chain are hierarchically
organized with functional and component requirements communicated down the
chain and components and assemblies moving up the chain for final assembly.
This works well within the mass production paradigm, but not within the
coming disruptive mass customization paradigm.
VEE: The Swarming Peer-to-Peer Supply Chain
As opposed to the integrated supply chain, the members of the
Virtual Extended Enterprise are not hierarchically organized. Instead,
all members of the supply chain are members of the same team and sit at the
same table. This enables swarming. When I was leading an advanced
IT development and integration lab for a major defense contractor, initially I
set up a hierarchical organization based on the conceptual design I had for the
effort.
The goal of the effort was to virtually locate aircraft engineers, from
multiple aircraft companies, rather than actually locate them. Up to the
early 1990s when there were joint efforts among major aerospace companies,
engineers from all of these companies would be sent to a single location
(generally the location of the contract winner) to be able to work together.
The engineers at this location would include only the prime contractor and
those in the second tier. Still, the costs to the program of moving and
temporarily housing all of those engineers (and sometimes their families) for
years became a significant cost. The job of our project was to use
technology to reduce and/or eliminate most of those costs.
Through the first six months our effort struggled. Then I started to
empower the team of initially 12 to 16 very smart, self-starting IT
professionals. Later on 8 to 20 aircraft engineers were added. I
would provide guidance of what was needed (the requirements and to some degree
the architecture (the structure and ordering of the processes) at a weekly team
meeting. The team would then identify the unknowns (risks) in potential
designs. After the meeting I would see groups form (specialty swarm)
to reduce the risks and to design and code products to meet the requirements.
These groups would assign themselves tasks to be accomplished during the
following week. At the end of the week the team had generally done an
astonishing amount of designing and development work. If the team or I
had identified a risk, that had not yet been reduced, a team member would bring
it up at the next meeting, and another group would form after the meeting to
reduce that risk. Again, swarming tactics. [Sidebar:
We actually used the virtual collocation environment (now called a
collaborative environment) ourselves. While it was against de jour
corporate policy, the products of our lab enabled two or three young ladies
with babies and toddlers to work from home; only coming in once a week for the
team meeting] Once I empowered the team to swarm, and moved away from
transactional management to transformational management, the project exceeded
the expectations of most of the corporate management.
While I admit this was on a very small scale, it demonstrates the power of the
VEE architecture and with swarming tactics for research and development
efforts, that is, turning unknowns into knowns (i.e., risk reduction).
And risk reduction through innovation is the key to new technology
insertion and process improvement (which means cost efficiency).
SOA and Swarming Tactics
Enter Services Oriented Architecture. Services are
components that serve a particular function and that have a standardized and
published interface, which can be linked to other services. This
combination for software is an analog to children's building blocks, of which
the best known are Legos.
Web Services, at the "application as a service" or the "Platform as a layer are one set of
building blocks. [Sidebar: In a typical SOA there are also,
Infrastructure as a Service (better known as a component of Cloud Computing),
and Data Center Facilities (also a component of Cloud Computing).] To be a "web service" the code must have one or more "published" interfaces that is XML-based.
The job of the development team for an implementation to enable and support some new organizational process is to assemble these Web Services by structuring and ordering them, while identifying missing services that the team will need to design, code, and implement. "Structuring and Ordering" sounds a whole like System Architecture; and it is exactly that.
While I've discussed Systems Architecture in other posts the part that's of interest in this post is the identification of missing functions and the design, development, and implementation of the functions, as well as their integration into the complete assemblage of the product. This is where the swarming tactics come in. Like my experience in the lab, the program manager, in this case using the transformational management style, would present the entire team with the unknown (risk item) and the team members would decide if that have talents or expertise that would contribute to creating a usable service; that is the essence of the swarming tactic applied to development and implementation. And, I've found that it's the only method that is both effective and cost efficient to creating innovative products, systems, and services.
