Link: http://organizational-economics.blogspot.com/2016/12/if-you-want-to-create-enterprise.html
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.
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.
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?
“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
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.
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.
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.
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.
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.
