CFO and CTO Versus CPO

The CFO and CTO

In this age, 1990 to 2020, the Chief Financial Officer (a financial engineer) is boss in most companies and corporations and the goal is "INCREASING STOCKHOLDER VALUE".  This includes everything from selling the company, to cooking the books, to reducing the wages, retirement, and benefits to the employee, to selling technology and knowledge to the Chinese.

In these companies and corporations, the CEO decides on a direction then asked the CFO if it is OK.  Twice I saw this for myself.  Once the CEO of a company I worked for decide to build a new plant.  This was short-term dumb, because it would reduce the next quarter's profit, but was long-term smart because the company would, and did, survive and thrive.  When the CFO said no, the CEO fired the CFO because the CEO was the son of the founder and owner.

In the second instance I saw the CFO reduce a major defense contractor from an integrated and high-morale team of over 50,000 to less than 25,000 demoralized  employees (where one Vice President call the employees "assets" that he could move or layoff at his discretion.  This was done so that the stockholders and management could make "windfall profits" when the company was sold. 

All of this weakens the economy of the nation and reduces the average worker's income, and shorten the life-span of the organization, because of the "economic lamprey eels" known as crony capitalists and day-traders.

While Chief Technology Officers don't have the political power of the Chief Financial Officers, but they too can wreck a company.  They do this by investing too much in some technologies and/or too little in others.

Frequently, they do this at the behest of the CEO, CFO, or VP of Marketing.  There are four reasons.  

First, because these individuals have read something or been to a conference of some product.  They insist that the product be used because they believe the advertising and they do not want to spend money on comparative evaluation. On several occasions, I've seen where this has led to total failure of the effort.

I've seen projects, with budgets in the tens of millions, fail due lack of requirements.  In several of these cases the supplier's of a particular product defined the requirements.  Surprise, their product was the only one to meet the requirements even though it didn't meet the users' needs and requirements.

Second, because the CFO or CTO has set a policy, including policies that require all units in a large organization to use the same tooling for different jobs or not use a tool, even though its the right tool for the job (project or program).  I had this happen to me.

In one case, I was part of a team that was using a new tool from IBM for building websites.  The tool required that we have a minimum of a 19" display to help us use the tool properly.  It took weeks before the team could get a waver to get the larger screens, then they magically disappeared on to the desks of the personnel that installed new systems.  Again, it took some doing before we had the displays we needed.

In the early and middle 1980s, I was innovating on data communications with expertise in Local Area Networks.  I had just finished leading a team that created a paperless shop floor factory system for improving its effectiveness and cost efficiency.  It used standardized protocols like 802.3 (Ethernet).  I created the shop floor network in less than 90 days that I was told was needed (otherwise I would get fired) and at half the budget allocated by IBM for the effort.  And it worked; the system won the Society of Manufacturing Engineers Lead award.

I then accepted employment at a major defense contractor of the time.  They too, were attempting to automate the shop floor of one of their factories.  They actually had employees on bicycles running around on the shop floor--they people were call expediters.  Again, I recommended the solution to the project manager.  However, the project manager decided it work because it didn't use the IBM tools and therefore it came from the wrong vendor.  One year and tens of millions of dollars later the project failed.  However, due to the next reason the project manager--a she--became a Vice President and the technical employees were RIFed.

The third reason CTOs fail is politics.  In all industries in the US, but particularly in government related industries in the US, politics always trumps competence.  Minority and female-owned businesses must always be given a percentage of the work, whether or not they are competent.  In several proposal efforts the personnel in the lab I led had to finish creating a concept demonstration in a few hours after these "firms" spent months not completing the job.

And they must fill a certain number of upper level positions whether or not they are competent.  I was interesting to me these female directors and VPs required an IT assistant to do their job as an IT VP.  This is the fourth reason CTOs fail, sheer incompetence.

One thing that these "politically correct" managers insisted on was that the technical team meet all of their foggy vague technical requirements with in a short period and on a preset budget.  After I attempted to refine the technical requirements I found that it would take twice the budget, that is a minimum of $20 million, as the $10 million could only meet about half their requirements in the time they specified.

When I recommended that we construct the system with an Initial Operating Capability (IOC) and then add components to meet the unmet requirements, they gave an unqualified NO!  They were asking for the equivalent of building a 10,000 sq. ft custom beachfront home in "the Hamptons" with an infinity pool and 4 car garage in 3 months for $100,000.  The project was predestined to fail.

For example, I recommended buying and installing a small computer system so that we could evaluate the new system.  It took from February until August to get the 33 thousand dollar system approved.  In the meantime the space allocated for it was taken up by other equipment and it sat outside for several months until space could be found. 

When we finally had a first version running, because of the bureaucratic gears grinding slowly and oh so finely I was told that we could not test the system because of the lateness; we had to meet the schedule.  No testing the system failed.

I could give many more examples of the failures of this type.  I could see these coming but didn't have the social or political skills to call a spade a pointy club.  Still finance engineering, politics, and social engineering wrecked many, many projects and programs.

A Chief Process Officer

However, there is a better way.  But it's one not taught in business colleges of Universities.  That's because it doesn't focus on finance, accounting, management, or marketing.  Instead, it focuses on the enterprise's economic engine and supporting infrastructure.   It's the organization process for creating value for its customers.

Typically, the business schools focus of the economic battery of the organization.  Think of a car's battery.  While it starts the engine it then provides the electricity that runs all of the accessories, from power windows to stereos and navigation systems--now even the accelerator pedal uses electricity.  The organization's economic battery is siphoned by the management and stockholders of the organization's profit, totally ignoring the economic engine--the company's processes and infrastructure.

If the organization had a Chief Process Officer (CPO) similar, but not identical to the Chief Operating Officer (COO), a job that has been eliminated by most companies to be replaced by the CFO.  The COO was responsible for the day to day operations of the organization's economic engine.  The job of the CPO would architect/design processes, standards, policies, tooling, and knowledge/training/talent to support the the vision, mission, or goal(s) of the organization as identified or defined by the CEO.

The CPO is responsible and accountable for:

• First, the processes to ensure that the organization's customer(s) get the product, system, or service that meets their requirements.
• Second, the standards and policies that enable and support the process.
• Third, the knowledge and talents required by the process.
• Fourth, the tooling and equipment needed for the process.

The staff of the CPO would include:

• The personnel officer accountable for hiring, training, or at worst contracting personnel with the required knowledge and/or talents required.
• The Chief Process Architect who is accountable for modeling the current and potential future process architecture.  The architect's team would include a number of systems engineers, technology specialists, and systems architects.
• The systems engineers would identify and manage the customer's requirements and design and process risks
• The technology specialist would identify and evaluate potential technological solutions.
• The systems/enterprise architects would model the current and future processes to determine if the current process(es), technologies, standards and policies can be made (first) more effective in meeting the customers requirements, and (second) more cost efficient.

• The Chief Financial Officer providing financial data to the modeling team.

With this organizational structure, the would provide better products, systems, or services to the customer and more cost efficiency for the organization,

Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes

Regulations: The “Must Meet” Requirements

Regulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting its charter, goal, or in completing its mission.  This post discusses laws, rules, specifications, standard, regulations (or simply regulations) as a part of any enterprise architecture or systems engineering effort.

The Customer Requirements Identification and Management tool that I’ve developed, CARRMA^®, uses the concept of Must Meet requirements to store both the regulations and the metrics for meeting the regulation.  If more than one project has a particular regulation imposed on it, the CARRMA^®’s data store will allow for reuse.

Regulations the rudders of an organization

Any commandment, law, rule, specification, standard, or regulation creates process friction, by its very nature.  It inhibits what can be done or defines what must be done. For example, saying “Thou Shall not Kill” means that it’s not nice to end a vehemently intense discussion by bouncing your opponent “six feet under”, though that might be very satisfying at the moment.  That is, killing is not a good solution to an intra-group disagreement since it doesn’t promote understanding, knowledge and therefore value growth of the group and doesn’t instill trust with other groups.

Hoping that I’ve made the point that regulations curb action or ensure action, by an over-the-top example, a regulation acts like a rudder, making it difficult for a process and thus a strategy to go one way, thereby making it easier to go another.  This, in turn, may directly affect the organization’s charter, mission, or goal.  In any rational system it should enable both the charter/mission/goal and the strategies and processes for achieving these.

Fortunately or more importantly, unfortunately systems and organizations built by humans are not entirely rational and sometimes not rational at all.  If the economy is the engine that powers the ship-of-state in an organization, then each commandment, law, rule, specification, standard, or regulation enacted is a rudder with its own wheel guided by part of the crew steering the organization toward their own Avalon.

Arrow’s Paradox and Catch 22s

At some point the number of rudders pointing at all points of the compass are such that the organization be it private or a ship-of-state either comes to a complete halt or turns in tight circles.  The rudders have formed a damn that effectively stops all forward progress of the organization, which no amount of churning by the organization’s economic engine can overcome.  Some of these regulation rudders are small and some are very large.  Twist the large ones hard and the ship brakes to a crawl and it may not turn at all. 

Arrow’s Paradox

A bigger problem is that too many regulation rudders will simply cause the organizational ship to stop and not make any of the ports.  Dr. Kenneth Arrow’s is known for “Arrow’s Impossibility Theorem” [Sidebar: For which he won the Nobel Prize], which is also known as Arrow’s Paradox.  He demonstrated mathematically that if an organization has three or more goals that they want to optimize, they will be able to only optimize on two (or I suspect they can sub-optimize on all three).

The point here isn’t that organizations can’t have more than one goal or objective; it is that if the organization attempts to define more than two (or maybe three) objectives using the “policy/regulation” strategy, the organization will slow down, wobble around, and achieve none of the objectives.

If you add in that in a democracy the goals and objectives change as controlling constituencies change, normally you end up with more and more laws, regulations, rules, and standards each attempting to use its regulatory rudder to change the course of the ship-of-state to reach the objective for which it was enacted.  The net result is that either the ship-of-state will end up on the rocks or going in circles.

From personal experience with federal contracts and from a recent DoD report, I can illustrate the problem.  One goal, which probably should be the only goal of DoD contracting, is to provide the most effective weapons in the world for the US Military.  That is, the weapons should be the greatest force multiplier.

However, the contracting office is faced with a second objective (a second rudder) of acquiring these weapons cost efficiently.  There are two metrics for cost efficiency, the initial cost (including research, development, and construction), and life-cycle costs (maintenance, upgrades, and disposal).  The question for the contracting officer is, “Do you contract for the cheapest initial cost product or for the one that will cost the least over the product’s projected lifespan?”

Then there is a third rudder in the form of the dependability of the product, system, or service. “Dependability encompasses all of the “illities”, including reliability, maintainability, serviceability, and so on.  Each of these has metrics and standards that must be met.  In some cases the metrics for the standard or policy is either untestable in a timely manner or in a few infeasible or impossible to meet.  All of these rudders will force addition time and expense into the effort.

A fourth rudder is reconfigurability and upgradeability of the product, system, or service.  Before the US Civil War, the rate of change of weapons and support systems was such that weapons and weapons systems had no need for this “Must Meet” requirement/policy.  The weapon would be worn out long be the technology changed.  However, since then it’s obvious that technology has and is continuing to accelerate (to the point that for many systems, they must be upgraded before their development and implementation is completed).  These continue to increase the initial design costs. [Sidebar: Services Oriented Architecture can reduce these costs greatly for IT systems, and modular systems/product can do the same for hardware of all types.]

A fifth rudder, and first one that is politically/social motivated as well as costly is the implied policy that all congressional districts and states should have jobs related to weapons and intelligence system development, especially where the senator or representative sits on committees dealing with budgets and military programs.  A recent DoD study has shown that this can add 20 to 25 percent to the cost of a product, system, or service for the DoD.

Then comes the politically motivated socially liberal welfare policy rudders (those intended to regulate social welfare and social change).  For weapons and intelligence tools, these require that a certain percent of the work on the product be from female owned companies and another percentage be from “minority” owned businesses.  [Sidebar:  The social actives’ idea was that the only way these groups could break into DoD contracting was through regulation.  I think they were correct because most of the work they did that I observed over the 25 years I was associate with government contracted engineering demonstrated beyond a doubt that they were incompetent to compete with a level playing field.  Many times the prime contractor had to supply the engineering capability to complete the job over schedule and way over cost.]  While it isn’t Politically Correct to attempt to define how much money was spent on this contracting welfare, from personal experience I expect that it is very significant.

The point of this section is not to discuss the problems with the regulations and informal policies of DoD contracting, rather it’s to demonstrate that as more laws, policies, regulations, business rules, standards, and so on (the “Must Meet” requirements) are imposed on a program, especially, extraneous ones, that both the effectiveness of product and the cost efficiency of the project or program are reduced.  And at some point there are so many “Must Meet” requirements that the effort, even at the enterprise architectural level will fail.

Catch-22

The extreme case of Arrow’s Paradox is the famous Catch-22 where two regulations are diametrically opposed leaving whatever effort, project, program, organization, or enterprise going in circles and making no progress in any direction. Even with a ship-of-state the size of the United States (which is a supertanker sized economy), given enough Catch-22s and nothing will get done; too many steersmen, too many rudders, and too many goals (targets, harbors, or whatever).

A good current and everyday example of regulatory Catch-22 is deicing roads.  Having icy sidewalks can be very exciting and occasionally lethal—so it really is not a good thing.  So deicing the sidewalks is mandatory.  Deicing calls for the use chemicals like sodium chloride (salt).

The problem is that there are regulations (must meet) requirements for the use and storage of “salt” because it “pollutes the environment” (and it does, you should see my grass near the sidewalk and road).  So you must use chemicals to save lives but you must not to save the environment.  Two regulatory “must meet” requirements (rudders) are in opposition, one to save lives and one to save the environment.  This is a small example of a big problem that can and will bring the economic ship-of-state to a dead stop.

Reducing the Number of Regulatory Brakes but Keeping the Rudders

To get any organization to at least head to a goal it should be clear that removing internal policies that interfere with the attainment of the goal is necessary.  For large organizations with many sub-organizations, the issue becomes one of identifying which regulations guide the organization in the direction its charter, goal, or mission state and which are braking it to a stop.  For many organizations, but especially democratic style governments, there will always conflicting goals and missions and therefore conflicting regulations.  So how should a large organization or government determine which are rudders and which are brakes?

To my mind, this is a good place to apply Enterprise Architecture and the architectural model that I set out both in my book and in this blog.  The nice thing about that architectural model is that it can start as a static model that can be used to identify customer requirements and end up as a dynamic model of the enterprise (even the Ship-of-State).  As such, it can identify policies that are braking or causing bottlenecks in the processes enabling the strategies for attaining the goal or mission.  Until you can dynamically model the enterprise, you will never really be able to identify the unintended consequences and negative externalities of any policy, standard, or regulation.  Nor, as the goal or mission changes can you identify those policies, standards, or regulations that truly impede progress in the changed direction (though many politicians in the organization will be able to tell you, or so they believe).

For those policies and standards internal to the organization, the leadership should be able to understand which regulations support the organization’s strategies and process and which don’t.  Additionally, the leadership can propose changes, deletions, and new regulations, which the enterprise architect can then model to determine the likely consequences, both intended and unintended.  Once the enterprise architects have oriented the changes the leadership proposes [Sidebar: See the OODA loop] the leadership can then choose what internal policies, standards, and regulations to change and which changes to implement with a much lower risk while seeing the their organization move more quickly toward achieving its goal.  [Sidebar: The modeling will also show where leaders and managers of sub-units are working on their own agenda which might or might not be steering toward the overall goal.  Remember the Systems Engineering axiom, “Optimizing the sub-systems sub-optimizes the system.”]

For governments, especially for the legislative branch, architectural modeling is particularly important both to determine conflicting laws, regulations, rules, standards and codes.  If, as the architectural models mature and their predictions help to make better decisions, there may even be fewer vehemently intense discussions about which laws, regulations, rules, standards, and codes to enact and which to remove or rewrite…Interesting.

If You Want to Create an Enterprise Architecture; Don't!

One of the last presentations I made as an Enterprise Architect for a major DoD contractor was to the Chief Architect of the US Veterans Administration.  I walked in with a fully prepared presentation that was to take about 10 minutes of the time allotted to our team only to find the Chief Architect cutting the presentation off with a question, "How do we go about creating an IT architecture for the VA?"  Even though I had a very good answer and had applied it on a couple of occasion, my mind blanked.  I want to share with you his problem and the answer I should have given.

The Problem

The problem that the Chief Architect of the VA has is the same problem that plagues CA's of all large organization and most of medium and smaller organizations.  That question is base on the very logical idea very much the analog of the idea that before you start changing the plumbing, you should know design of the current plumbing; that is, before you can create a "to be" or "next step" architecture you need to have a "current architecture".  Obviously, if you don't know which pipes connect where and start making changes to the plumbing you could end up with some very interesting and exciting results for which you may need to call your insurance company.  Likewise, if you want to improve the effectiveness and/or the cost efficiency of the organizational processes and information systems, most Enterprise Architects assume they must first define and delimit the "as-is" processes and information systems for the organization.

The conundrum is that, in today's technological environment, by the time an IT architecture team has mapped out (structured and ordered) an "as is" architecture, some, most, or all of the elements and data of the architecture will be obsolete and out of date.  For something as large as a major corporation, a department within a state or the federal government, the cost and effort involved would require a tour de force on a very large perhaps unprecedented scale.  This cost and level of effort would be such that the senior management would cut funding to the effort as a waste of time and money, since having an "as-is" architecture by itself produces little in value to the organization.

As can be found in the literature, there are many ways to "solve" or at least ameliorate the problem of creating an "as-is" architecture.  For example, one of the best, that almost works, is to chop the organization into its components and create an "as-is" architecture for each component separately.  Then try to stitch the architectures together.  I've tried this and it works up to a point.

There is a truism in Systems Engineering, Systems Architecture, and Enterprise Architecture, "Optimizing the sub-systems will sub-optimize the system".  I have demonstrated this to many people many times and experienced it several times.  But this is crux of the problem for those that try to create an Enterprise Architecture for a large organization.

The Solution

The simple answer is "Don't".  That is, "Don't attempt to create an "as is" architecture for an organization, especially a large organization, because it will create itself with the proper procedures in place.  So how would I do it?

1. Define, delimited, and structured an initial set of classes and attributes for the Organization's Enterprise Architecture.  These should include:

• Its Charter, Mission, Goal
• Its Strategies for achieving its charter, mission, or goal
• Its Processes supporting its strategies
• Its Tooling and infrastructure
• Its Governance that affects any of the above, including:
• Internal Policies and Standards
• External Regulations and Standards

I worked with one Enterprise Architecture database that had over fifty classes, each class with ten or more attributes.  This was a fairly mature architecture.  My recommendation, don't try to think of all the classes you may need or all of the attributes for each class; that's way over thinking.  Instead, start simple and add through the cycles

2. Once you have designed and structured the initial set of classed and attributes, create a data base structured according to the design.

3. Here is the key to creating an "As-Is" Architecture by not creating it...Huh?  Design and implement processes to capture the current state of strategies, processes, and tooling/infrastructure as part of review of funding for revision and upgrades to the current systems and processes.  

4. When personnel in the organization propose a project insist that these personnel demonstrate the value of the process or procedure that they intend to update or upgrade. The "value" would include demonstrating which of and how the current product, system, or service enables the processes, strategies, and charter, mission, or goal of the organization. My experience has been that the initial attempts will be fuzzy and incomplete, but that as the number of proposed projects in the database (which is generally called the Asset Management System and on which the "as-is" architecture is built) increases both the completeness and clarity of the current enterprise architecture will increase.

The reason I say "Don't" try to create an "as-is" architecture is that every 3 to 7 years every component of the organization's information system will need replacement.  This means that within 3 to 5 years simply by documenting and structuring the inputs from all of the efforts the organization's "as-is" architecture will be synergistically created (and at minimal cost) [Sidebar: There will be some cost because the project proposers will need to think through how their current charter, mission, or goal and the strategies they support links to and supports the overall charter, mission, or goal of the organization.  This is not necessarily a bad thing.]  For large organizations, no matter how much time or effort is put into attempting to create an "As-Is" Enterprise Architecture, it will take a minimum of a year and a great deal of funding; so it simply makes no sense.

As this Enterprise Architecture evolves you will begin to see a number of things that managers want to obfuscate or hide completely.  For example, a number of processes and component or sub-organizations will be demonstrated to be obsolete.  In this case obsolete means that the process or component organization no longer supports any of the organization's strategies or its goal.  Since managers want to build or at least keep their fiefdoms they will not appreciate this much.  Additionally, it will demonstrate which internal policies, regulations, and standards help the organization and which hurt it in meeting its goal.  Again, the gatekeepers of these policies, regulations, and standards will object--strenuously.  

But there are two more insidious problems that a good "As-Is" Enterprise Architecture will reveal, nepotism and the famous "Catch-22s".  

Nepotism

Nepotism in this case is more broadly defined than what most people think of as "nepotism".  In the sense I mean, nepotism can include creating a non-level economic playing field. In all large organizations, but especially in the U.S. Federal government (probably in all governments) the type of nepotism I’m identifying is rampant.  In fact a December 2016 report from the Department of Defense highlights what most federal employees and DoD contractors have known for years, because representatives and senators will only vote for a large program if their district or state gets a part of it, the DoD estimates that the cost of the program increases approximately 20 percent.  This is "jobs welfare" on a massive scale.  Some major defense contractors have plants in every state for just this reason, not because it make any sense from a cost efficiency perspective.  Further, Congress had passed laws to ensure that minority and female owned businesses.  The reason is that minorities and women scream that the good old boy network doesn't allow them to compete for sub-contracts [Sidebar: Actually the reason for the "good ole boy" network is that the prime contractors have sub-contractors that actually know what their doing.  In my experience, many times primes will "encourage"--read subsidize--inexperienced and frequently incompetent minority and female owned businesses in order to meet these regulations imposed on their proposals.]  Again, this is a form of social welfare to ensure all political constituents that scream loudly are appeased.  This adds up to the DoD being one of the larger governmental welfare organizations. [Sidebar: While, seemingly, I've picked on government organizations, especially the U.S. DoD, and while I have found that all governmental organizations in a democracy will have this type of nepotism.  This is what lobbing is all about.  Only when it goes so far that it's plain to all and when it's not openly enacted into law that we call it graft and corruption.]  And it's not only governments that suffer from this type of nepotism, all large organizations have the same problems, though generally on a smaller scale.  For example, sometimes the nepotism is written into union contracts.  Along with finance engineering, the auto industry in Detroit suffered a near collapse due to contractual nepotism.

This presents a problem for any Enterprise Architect.  The as-is architecture will highlight the nepotism of this type more clearly than any report.  The Enterprise Architect won't need to report it to the management, it will be self-evident.  I've experienced a situation, as I suspect many of you have, where the management kills the messenger in order to not address the problem.  In my case, three times I've been chased off programs when I reported that the effort was subsidizing silliness.

Catch-22

The second significant problem that policies, regulations, and standards become contradictory to each other or in combination make it impossible for the organization to achieve its goal.  Again, a good enterprise architecture will highlight these, though frequently, when management from one generation of technology with its set of policies and standards, finds the next upon them, they will refuse to resend or modify the existing regulations, preferring instead, again, to kill the messenger.  So like Systems Engineers, I've found that enterprise architects are only respected by other enterprise architects.

5. When the development and implementation team completes a project, and once it goes into operation, then as a final step in their effort, they should review the data they gave to the enterprise architect, revising the data to accurately reflect the "as-built" instead of the "as-proposed".  The as-built documentation must include all component, assembly or functional, and customer acceptance testing, and all post production required changes.  This documentation will inevitably lead to additional class attributes of the Asset Management System and structure in the enterprise architecture.

6. As the Asset Management System and the Enterprise Architecture matures, management should prepare for a paradigm shift in the way projects and other efforts are proposed.  This is where Enterprise Architecture really demonstrates how it can make the organization both more effective and cost efficient.

A mature enterprise architecture can serve as the basis for a dynamic business or organizational process model for the organization.  Management can use this model to identify obsolete processes, (and as discussed) policies, regulations, and standards; ones that the organization should eliminate.  Additionally, with the help of the Enterprise Architect, management can identify missing or inhibiting processes and tools, and identify bottlenecks and dams in process flows.

Further, they can model what happens when the missing and inhibiting processes and tools are added or when the bottlenecks are eliminated or reduced.  This modeling will then indicate where there is a need for new efforts and to some degree the effectiveness and cost efficiency of such efforts.  It's a paradigm shift in that no longer to component or sub-units of the organization propose changes.  Instead, senior management working with the Enterprise Architect and the component or sub-units will identify and fund efforts.  They now have a way to measure the potential of the change in meeting the organizational goal, which means senior management has a better way of managing organizational change.

Finally, once management has identified targets for change or upgrade, the enterprise architect together with a system architect can define alternatives to meet the effort's requirements.  They can model alternative process and tooling changes to forecast which has the lowest potential risk, the highest potential return, the least disruption of current activities, lowest initial cost, lowest lifecycle cost, the most adaptable or agile, or any number of other targets defined by the senior management.  This will make the organization much more cost efficient, and perhaps more cost effective; and this is the purpose of Enterprise Architecture,

To sum up, using this six step, high-level process is an effective way to create both an Asset Management System (an "As-Is" Architecture) and an effective Enterprise Architecture process; perhaps the only way.  

Agility, SOA, Virtual Extended Enterprise, Swarming Tactics, and Architecture

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.