Welcome to a special BriefingsDirect presentation and panel discussion from
The Open Group San Diego 2015, which ran Feb. 2 through Feb. 5.
The following discussion, which examines the synergy among the major
enterprise architecture frameworks, consists of moderator
Allen Brown, President and Chief Executive Officer, The Open Group;
Iver Band, an Enterprise Architect at
Cambia Health Solutions;
Dr. Beryl Bellman, Academic Director,
FEAC Institute;
John Zachman, Chairman and CEO of
Zachman International, and originator of the
Zachman Framework; and
Chris Forde,
General Manager, Asia and Pacific Region and Vice President, Enterprise
Architecture, The Open Group. [Disclosure: The Open Group is a sponsor
of BriefingsDirect podcasts.] Download a
copy of the transcript.
Here are some excepts:
Iver Band: As an
enterprise architect at
Cambia Health Solutions, I have been working with the ArchiMate Language for over four years now, both working with and on it in the
ArchiMate Forum. As soon as I discovered it in late 2010, I could immediately see, as an enterprise architect, how it filled an important gap.
What is the ArchiMate Language? Well, it's a language
we use for building understanding across disciplines in an organization
and communicating and managing change. It’s a graphical notation with
formal semantics. It’s a language.
It’s a framework
that describes and relates the business, application, and technology
layers of an enterprise, and it has extensions for modelling motivation,
which includes business strategy, external factors affecting the
organization, requirements for putting them altogether and for showing
them from different stakeholder perspectives.
You can
show conflicting stakeholder perspectives, and even politics. I've used
it to model organizational politics that were preventing a project from
going forward.
It has a rich set of techniques in its
viewpoint mechanism for visualizing and analyzing what’s going on in
your enterprise. Those viewpoints are tailored to different
stakeholders. And, of course, ArchiMate, like
TOGAF, is an
open standard managed by The Open Group.
Taste of Archimate
This
is just a taste of
ArchiMate for people who haven’t seen it before.
This is actually excerpted from the presentation my colleague
Chris McCurdy and I are doing at this conference on Guiding Agile Solution Delivery with the ArchiMate Language.
What this shows is the Business and Application
Layers of ArchiMate. It shows a business process at the top. Each
process is represented by a symbol. It shows a data model of business
objects, then, at the next layer, in yellow.
Below that, it shows a data model actually realized by the application, the actual data that’s being processed.
Below
that, it shows an application collaboration, a set of applications
working together, that reads and writes that data and realizes the
business data model that our business processes use.
All in all, it presents a vision of an integrated project management toolset for a particular
SDLC that uses the phases that you see across the top.
We
are going to dissect this model, how you would build it, and how you
would develop it in an agile environment in our presentation tomorrow.
I
have done some analysis of The Zachman Framework, comparing it to the
ArchiMate Language. What’s really clear is that ArchiMate supports
enterprise architecture with The Zachman Framework. You see a rendering
of The Zachman Framework and then you see a rendering of the components
of the ArchiMate Language. You see the Business Layer, the Application
Layer, the Technology Layer, its ability to express information,
behavior, and structure, and then the Motivation and Implementation and
Migration extensions.
So how does it support it? Well,
there are two key things here. The first is that ArchiMate models
answer the questions that are posed by The Zachman Framework columns.
For
what: for Inventory. We are basically talking about what is in the
organization. There are Business and Data Objects, Products, Contracts,
Value, and Meaning.
For how: for process. We can model
Business Processes and Functions. We can model Flow and Triggering
Relationships between them.
Where: for the
Distribution of our assets. We can model Locations, we can model
Devices, and we can model Networks, depending on how you define Location
within a network or within a geography.
For who: We can model Responsibility, with Business Actors, Collaborations, and Roles.
When:
for Timing. We have Business Events, Plateaus of System Evolution,
relatively stable systems states, and we have Triggering Relationships.
Why:
We have a rich Motivation extension, Stakeholders, Drivers,
Assessments, Principles, Goals, Requirements, etc., and we show how
those different components influence and realize each other.
Zachman perspectives
Finally,
ArchiMate models express The Zachman Row Perspectives. For the
contextual or boundary perspective, where Scope Lists are required, we
can make catalogs of ArchiMate Concepts. ArchiMate has broad tool
support, and in a repository-based tool, while ArchiMate is a graphical
language, you can very easily take list of concepts, as I do regularly,
and put them in catalog or metrics form. So it’s easy to come up with
those Scope Lists.
Secondly, for the Conceptual area, the Business
Model, we have a rich set of Business Layer Viewpoints. Like the top of
the -- that focus on the top of the diagram that I showed you; Business
Processes, Actors, Collaborations, Interfaces, Business Services that
are brought to market.
Then at the Logical Layer we
have System. We have a rich set of Application Layer Viewpoints and
Viewpoints that show how Applications use Infrastructure.
For Physical, we have an Infrastructure Layer, which can be used to model any type of Infrastructure:
Hosting,
Network,
Storage,
Virtualization, Distribution, and
Failover. All those types of things can be modeled.
And
for Configuration and Instantiation, the Application and Technology
Layer Viewpoints are available, particularly more detailed ones, but are
also important is the Mappings to standard design languages such as
BPMN,
UML and
ERD.
Those are straightforward for experienced modelers. We also have a
white paper on using the ArchiMate language with UML. Thank you.
Dr. Beryl Bellman:
I have been doing enterprise architecture for quite a long time, for
what you call pre-enterprise architecture work, probably about 30 years,
and I first met John Zachman well over 20 years ago.
In addition to being an enterprise architect I am
also a University Professor at California State University, Los Angeles.
My focus there is on Organizational Communications. While being a
professor, I always have been involved in doing contract consulting for
companies like
Digital Equipment Corporation, ASK,
AT and T,
NCR, then
Ptech.
About
15 years ago, a colleague of mine and I founded the FEAC Institute. The
initial name for that was the Federal Enterprise Architecture
Certification Institute, and then we changed it to Federated. It
actually goes by both names.
The business driver of that was the
Clinger–Cohen Bill in 1996 when it was mandated by government that all federal agencies must have an enterprise architecture.
And then around 2000, they began to enforce that regulation. My business partner at that time,
Felix Rausch,
and I felt that we need some certification in how to go about doing and
meeting those requirements, both for the federal agencies and the
Department of Defense. And so that's when we created the FEAC Institute.
Beginning of FEAC
In
our first course, we had the Executive Office of the President, US
Department of Fed, which I believe was the first Department of the
Federal Government that was hit by
OMB
which held up their budget for not having an enterprise architecture on
file. So they were pretty desperate, and that began the first of the
beginning of the FEAC.
Since that time, a lot of people have come in from
the commercial world and from international areas. And the idea of FEAC
was that you start off with learning how to do enterprise architecture.
In a lot of programs, including TOGAF, you sort of have to already know a
little bit about enterprise architecture, the hermeneutical circle. You
have to know what it is to know.
In FEAC we had a
position that you want to provide training and educating in how to do
enterprise architecture that will get you from a beginning state to be
able to take full responsibility for work doing enterprise architecture
in a matter of three months. It’s associated with the California State
University System, and you can get, if you so desire, 12 graduate
academic units in Engineering Management that can be applied toward a
degree or you can get continuing education units.
So
that’s how we began that. Then, a couple of years ago, my business
partner decided he wanted to retire, and fortunately there was this guy
named John Zachman, who will never retire. He's a lot younger than all
of us in this room, right? So he purchased the FEAC Institute.
I
still maintain a relationship with it as Academic Director, in which
primarily my responsibilities are as a liaison to the universities. My
colleague,
Cort Coghill, is sort of the Academic Coordinator of the FEAC Institute.
You're just getting a snapshot in time and you're really not having an
enterprise architecture that is able to adapt and change. You might be
able to have a picture of it, but that’s all you really have.
FEAC
is an organization that also incorporates a lot of the training and
education programs of Zachman International, which includes managing the
FEAC TOGAF courses, as well as the Zachman certified courses, which we
will tell you more about.
I'm just a little bit
surprised by this idea, the panel, the way we are constructed here,
because I didn’t have a presentation. I'm doing it off the top, as you
can see. I was told we are supposed to have a panel discussion about the
synergies of enterprise architecture. So I prepared in my mind the
synergies between the different enterprise architectures that are out
there.
For that, I just wanted to make a strong point.
I wanted to talk about synergy like a bifurcation between on the one
hand, "TOGAF and Zachman" as being standing on one side, whereas the
statement has been made earlier this morning and throughout the meeting
is "TOGAF and."
Likewise, we have Zachman, and it’s
not "Zachman or, but it’s "Zachman and." Zachman provides that ontology,
as John talks about it in his periodic table of basic elements of
primitives through which we can constitute any enterprise architecture.
To attempt to build an architecture out of composites and then venting
composites and just modeling you're just getting a snapshot in time and
you're really not having an enterprise architecture that is able to
adapt and change. You might be able to have a picture of it, but that’s
all you really have.
That’s the power of The Zachman
Framework. Hopefully, most of you will attend our demonstration this
afternoon and a workshop where we are actually going to have people work
with building primitives and looking at the relationship of primitives,
the composites with a case study.
Getting lost
On the other side of that,
Schekkerman
wrote something about the forest of architectural frameworks and
getting lost in that. There are a lot of enterprise architectural
frameworks out there.
I'm not counting TOGAF, because
TOGAF has its own architectural content metamodel, with its own
artifacts, but those does not require one to use the artifacts in the
architectural content metamodel. They suggest that you can use
DoDAF. You can use
MODAF. You can use commercial ones like NCR’s
GITP. You can use any one.
Those
are basically the competing models. Some of them are commercial-based,
where organizations have their own proprietary stamps and the names of
the artifacts, and the wrong names for it, and others want to give it
its own take.
I'm more familiar nowadays with the governmental sectors. For example,
FEAF,
Federal Enterprise Architecture Framework Version 2. Are you familiar
with that? Just go on the Internet, type in FEAF v2. Since Scott Bernard
has been the head, he is the Chief Architect for the US Government at
the OMB, he has developed a model of enterprise architecture, what he
calls the Architecture Cube Model, which is an iteration off of John's,
but he is pursuing a cube form rather than a triangle form.
I'm not counting TOGAF, because TOGAF has its own architectural content metamodel, with its own artifacts.
Also,
for him the FEAF-II, as enterprise architecture, fits into his FEAF-II,
because at the top level he has the strategic plans of an organization.
It goes down to different layers, but then, at one
point, it drops off and becomes not only a solution, but it gets into
the manufacturing of the solution. He has these whole series of
artifacts that pertain to these different layers, but at the lower
levels, you have a computer wiring closet diagram model, which is a
little bit more detailed than what we would consider to be at a level of
enterprise architecture.
Then you have the MODAF, the
DoDAF, and all of these other ones, where a lot of those compete with
each other more on the basis of political choices.
With
the MODAF, the British obviously don’t want to use DoDAF, they have
their own, but they are very similar to each other. One view, the
acquisition view, differs from the project view, but they do the same
things. You can define them in terms of each other.
Then there is the Canadian,
NAF,
and all that, and they are very similar. Now, we're trying to develop
the unified MODAF, DoDAF, and NAF architecture, UPDM, which is still in
its planning stages. So we are moving toward a more integrated system.
Allen Brown:
Let’s move on to some of the questions that folks are interested in.
Moving away from what the frameworks are, there is a question here. How
does enterprise architecture take advantage of the impact of new
emerging technologies like
social,
mobile,
analytics,
cloud, and so on?
Bidirectional change
John A. Zachman:
The change can take place in the enterprise either from the top, where
we change the context of the enterprise, or from the bottom, where we
change the technologies.
So technology is expressed in
the context of the enterprise, what I would call Rule 4, and that’s the
physical domain. And it’s the same way in any other -- the building
architecture, the airplane architecture, or anything. You can implement
the logic, the as-designed logic, in different technologies.
Whatever
the technology is, I made an observation that you want to engineer for
flexibility. You separate the independent variables. So you separate the
logic at Rule 3 from the physics of Rule 4, and then you can change
Rule 4 without changing Rule 3. Basically that’s the idea, so you can
accommodate whatever the emerging technologies are.
Bellman:
I would just continue with that. I agree with John. Thinking about the
synergy between the different architectures, basically every enterprise
architecture contains, or should contain, considerations of those
primitives. Then, it’s a matter of which a customer wants, which a
customer feels comfortable with? Basically as long as you have those
primitives defined, then you essentially can use any architecture. That
constitute the synergy between the architectures.
One of the jobs of an enterprise architect is to establish a view of the
organization that can be used to promote understanding and communicate
and manage change.
Band: I agree with
what's been said. It’s also true that I think that one of the jobs of an
enterprise architect is to establish a view of the organization that
can be used to promote understanding and communicate and manage change.
With cloud-based systems, they are generally based on metadata, and the
major platforms, like
Salesforce.com as an example. They publish their data models and their
APIs.
So
I think that there’s going to be a new generation of systems that
provide a continuously synchronized, real-time view of what's going on
in the enterprise. So the architectural model will model this in the
future, where things need to go, and they will do analyses, but we will
be using cloud, big data, and even sensor technologies to understand the
state of the enterprise.
Bellman: In the DoDaF
2.0, when that initially came out, I think it was six years ago or so,
they have services architecture, a services view, and a systems view.
And one of the points they make within the context, not as a footnote,
is that they expect the systems view to sort of disappear and there will
be a cloud view that will take its place. So I think you are right on
that.
Chris Forde: The way I interpreted the
question was, how does EA or architecture approach the things help you
manage disruptive things? And if you accept the idea that enterprise
architecture actually is a management discipline, it’s going to help you
ask the right questions to understand what you are dealing with, where
it should be positioned, what the risks and value proposition is around
those particular things, whether that’s the
Internet of Things, cloud computing, or all of these types of activities.
So
going back to the core of what Terry’s presentation was about is a
decision making framework with informed questions to help you understand
what you should be doing to either mitigate the risk, take advantage of
the innovation, and deploy the particular thing in a way that's useful
to your business. That’s the way I read the question.
Impact of sensors
Band:
Just to reinforce what Chris says, as an enterprise architect in
healthcare, one of the things that I am looking at very closely is the
evaluation of the impact of health sensor technology.
Gartner Group
says that by 2020, the average lifespan in a developed country will be
increased by six months due to mobile health monitoring.
And
so there are vast changes in the whole healthcare delivery system, of
which my company is at the center as a major healthcare payer and
investor in all sorts of healthcare companies. I use enterprise
architecture techniques to begin to understand the impact of that and
show the opportunities to our health insurance business.
Brown:
If you think about social and mobile and you look at the entire
enterprise architecture, now you are starting to expand that beyond the
limits of the organization, aren’t you? You're starting to look at, not
just the organization and the ecosystem, your business partners, but you
are also looking at the impact of bringing mobile devices into the
organization, of managers doing things on their own with cloud that
wasn't part of the architecture. You have got the relationship with
consumers out there that are using social and mobile. How do you capture
all of that in enterprise architecture?
An architecture can help you within your enterprise understand those
things and it can help you connect to other enterprises or other
information sources to allow you to make sense of all those things.
Forde: Allen, if I had the answer to that question I would form my own business and I would go sell it.
Back
in the day, when I was working in large organizations, we were talking
about the extended enterprise, that kind of ecosystem view of things.
And at that time the issue was more problematic. We knew we were in an
extended ecosystem, but we didn't really have the technologies that
effectively supported it.
The types of technologies
that are available today, the ones that The Open Group has white papers
about -- cloud computing, the Internet of Things, this sort of stuff --
architectures can help you classify those things. And the technologies
that are being deployed can help you track them, and they can help you
track them not as documents of the instance, but of the thing in real
time that is talking to you about what its state is, and what its future
state will be, and then you have to manage that information in vast
quantities.
So an architecture can help you within your
enterprise understand those things and it can help you connect to other
enterprises or other information sources to allow you to make sense of
all those things. But again, it's a question of scoping, filtering,
making sense, and abstracting -- that key phrase that John pointed out
earlier, of abstracting this stuff up to a level that is comprehensible
and not overwhelming.
Brown: So Iver, at Cambia Health, you must have this kind of problem now, mustn’t you?
Provide value
Band:
That's exactly what I am doing. I am figuring out what will be the
impact of certain technologies and how our businesses can use them to
differentiate and provide value.
In fact, I was just on a call this morning with
JeffSTAT,
because the whole ecosystem is changing, and we know that healthcare is
really changing. The current model is not financially sustainable, and
there is also tremendous amount of waste in our healthcare system today.
The executives of our company say that about a third of the $2.7
trillion and rising spent on healthcare in the US doesn't do anyone any
good.
There's a tremendous amount of IT investment in
that, and that requires architecture to tie it altogether. It has to do
with all the things ranging from the logic with which we edit claims, to
the follow-up we provide people with particularly dangerous and
consequently expensive diseases. So there is just a tremendous amount
going through an enterprise architecture. It’s necessary to have a
coherent narrative of what the organization needs to do.
The way we deal with complexity is through classification. I suggest that there is more than one way to classify things.
Bellman: One thing we all need to keep in mind is even more dynamic than that, if you believe even a little bit of
Kurzweil's
possibilities is that -- are people familiar with Ray Kurzweil's 'The
Singularity Is Near' -- 2037 will be around the singularly between
computers and human beings.
So I think that the wrap
where he argues that the amount of change is not linear but exponential,
and so in a sense you will never catch up, but you need an architecture
to manage that.
Zachman: The way we deal with
complexity is through classification. I suggest that there is more than
one way to classify things. One is one-dimensional classification,
taxonomy, or hierarchy, in effect, decompositions, one-dimensional
classification, and that's really helpful for manufacturing. From an
engineering standpoint of a two-dimensional classification, where we
have classified things so that they are normalized, one effect in one
place.
Then if you have the problems identified, you
can postulate several technology changes or several changes and simulate
the various implications of it.
The whole reason why I
do architecture has to do with change. You deal with extreme complexity
and then you have to accommodate extreme change. There is no other way
to deal with it. Humanity, for thousands of years, has not been able to
figure out a better way to deal with complexity and change other than
architecture.
Forde: Maybe we shouldn't apply architecture to some things.
For
example, maybe the technologies or the opportunity is so new, we need
to have the decision-making framework that says, you know what, let's
not try and figure out all this, just to self-control their stuff in
advance, okay? Let's let it run and see what happens, and then when it’s
at the appropriate point for architecture, let's apply it, this is a
more organic view of the way nature and life works than the enterprise
view of it.
So what I am saying is that architecture is
not irrelevant in that context. It's actually there is a part of the
decision-making framework to not architect something at this point in
time because it's inappropriate to do so.
Funding and budgeting
Band:
Yeah, I agree that wholeheartedly. If it can't be health solutions, we
are a completely agile shop. All the technology development is on the
same sprint cycle, and we have three-week sprints, but we also have
certain things that are still annual and wonderful like funding and
budgeting.
We live in a tension. People say, well,
what are you going to do, what budget do you need, but at the same time,
I haven't figured everything out. So I am constantly living in that gap
of what do I need to meet a certain milestone to get my project funded,
and what do I need to do to go forward? Obviously, in a fully agile
organization, all those things would be fluid. But then there's
financial reporting, and we would also have to be fluid too. So there
are barriers to that.
For instance, the
Scaled Agile Framework,
which I think is a fascinating thing, has a very clear place for
enterprise architecture. As Chris said, you don't want to do too much of
it in advance. I am constantly getting the gap between how can I
visualize what's going to happen a year out and how can I give the
development teams what they need for the sprint. So I am always living
in that paradox.
“The effective organization is garrulous, clumsy, superstitious, hypocritical, mostrous, octopoid, wandering, and grouchy."
Bellman:
The Gartner Group, not too long ago, came up with the concept of
emerging enterprise architecture and what we are dealing with.
Enterprises don't exist like buildings. A building is an object, but an
enterprise is a group of human beings communicating with one another.
As a very famous organizational psychologist
Karl Weick
once pointed out, “The effective organization is garrulous, clumsy,
superstitious, hypocritical, mostrous, octopoid, wandering, and
grouchy." Why? Because an organization is continually adapting,
continually changing, and continually adapting to the changing business
and technological landscape.
To expect anything other
than that is not having a realistic view of the enterprise. It is
emerging and it is a continually emerging phenomena. So in a sense,
having an architecture concept I would not contest, but architecting is
always worthwhile. It's like it's an organic phenomena, and that in
order to deal with that what we can also understand and have an
architecture for organic phenomena that change and rapidly adapt.
Brown: Chris, where you were going follows the lines of what great companies do, right?
There is a great book published about 30 years ago called ‘
In Search of Excellence.’
If you haven’t read it, I suggest that people do. Written by Peters and
Waterman, and Tom Peters has tried for ever since to try and recreate
something with that magic, but one of the lessons learned was what great
companies do, is something that goes simultaneous loose-tight
properties. So you let somethings be very tightly controlled, and other
things as are suggesting, let them flourish and see where they go before
I actually box them in. So that’s a good thought.
So
what do we think, as a panel, about evolving TOGAF to become an
engineering methodology as well as a manufacturing methodology?
Zachman: I really think it’s a good idea.
Brown: Chris, do you have any thoughts on that?
Interesting proposal
Forde:
I think it’s an interesting proposal and I think we need to look at it
fairly seriously. The Open Group approach to things is, don’t lock
people into a specific way of thinking, but we also advocate disciplined
approach to doing things. So I would susspect that we are going to be
exploring John’s proposal pretty seriously.
Brown:
You mentioned in your talk that decision-making process is a
precondition, the decision-making process to govern IT investments, and
the question that comes in is how about other types of investments
including facilities, inventory and acquisitions?
Forde:
The wording of the presentation was very specific. Most organizations
have a process or decision-making framework on an annual basis or
quarterly whatever the cycles are for allocation of funding to do X, Y
or Z. So the implication wasn’t that IT was the only space that it would
be applied.
In many organizations, or in a lot of organizations, the IT function is
essentially an enterprise-wide activity that’s supporting the financial
activities, the plant activities, these sorts of things.
However,
the question is how effective is that decision-making framework? In
many organizations, or in a lot of organizations, the IT function is
essentially an enterprise-wide activity that’s supporting the financial
activities, the plant activities, these sorts of things. So you have the
P and Ls from those things flowing in some way into the funding that
comes to the IT organization.
The question is, when
there are multiple complexities in an organization, multiple departments
with independent P and Ls, they are funding IT activities in a way that
may not be optimized, may or may not be optimized. For the architects,
in my view, one of the avenues for success is in inserting yourself into
that planning cycle and influencing, because normally the architecture
team does not have direct control over the spend, but influencing how
that spend goes.
Over time gradually improving the
enterprise’s ability to optimize and make effective the funding it
applies for IT to support the rest of the business.
Zachman: Yeah, I was just wondering, you’ve got to make observation.
Band:
I agree, I think that the battle to control shadow IT has been
permanently lost. We are in a technology obsessed society. Every
department wants to control some technology and even develop it to their
needs. There are some controls that you do have, and we do have some,
but we have core health insurance businesses that are nearly a 100 years
old.
Cambia is constantly investing and acquiring new
companies that are transforming healthcare. Cambia has over a 100
million customers all across the country even though our original
business was a set of regional health plans.
Build relationships
You
can't possibly rationalize all of everything I want you to pay for on
that thing. It is incumbent upon the architects, especially the senior
ones, to build relationships with the people in these organizations and
make sure everything is synergetic.
Many years ago,
there was a senior architect. I asked him what he did, and he said,
"Well, I'm just the glue. I go to a lot of meetings." There are
deliverables and deadlines too, but there is a part of consistently
building the relationships and noticing things, so that when there is
time to make a decision or someone needs something, it gets done right.
Zachman:
I was in London when Bank of America got bought by NationsBank, and it
was touted as the biggest banking merger in the history of the banking
industry.
If I was the CEO and my strategy was to grow by acquisition, I would get really interested in enterprise architecture.
Actually
it wasn’t a merger, it was an acquisition NationsBank acquired Bank of
America and then changed the name to Bank of America. There was a London
paper that was observing that the headline you always see is, “The
biggest merger in the history of the industry.” The headline you never
see is, “This merger didn't work.”
The cost of
integrating the two enterprises exceeded the value of the acquisition.
Therefore, we’re going to have to break this thing up in pieces and sell
off the pieces as surreptitiously as possible, so nobody will notice
that we buried any accounting notes someplace or other. You never see
that article. You’ll only see the one about the biggest merger.
If
I was the CEO and my strategy was to grow by acquisition, I would get
really interested in enterprise architecture. Because you have to be
able to anticipate the integration of the cost, if you want to merge two
enterprises. In fact, you’re changing the scope of the enterprise. I
have talked a little bit about the role on models, but you are changing
the scope. As soon as you change a scope, you’re now going to be faced
with an integration issue.
Therefore you have to make a
choice, scrap and rework. There is no way, after the fact, to integrate
parts that don’t fit together. So you’re gong to be faced a decision
whether you want to scrap and rework or not. I would get really
interested in enterprise architecture, because that's what you really
want to know before you make the expenditure. You acquire and obviously
you've already blown out all the money. So now you’ve got a problem.
Once
again, if I was the CEO and I want to grow by acquisition or merger
acquisition, I would get really interested in enterprise architecture.
Cultural issues
Beryl
Bellman: One of the big problems we are addressing here is also the
cultural and political problems of organizations or enterprises. You
could have the best design type of system, and if people and politics
don't agree, there are going to be these kind of conflicts.
I
was involved in my favorite projects at consulting. I was involved in
consulting with NCR, who was dealing with Hyundai and Samsung and trying
to get them together at a conjoint project. They kept fighting with
each other in terms of knowledge management, technology transfer, and
knowledge transfer. My role of it was to do an architecture of that
whole process.
It was called RIAC Research Institute in
Computer Technology. On one side of the table, you had Hyundai and
Samsung. On the other side of the table, you had NCR. They were throwing
PowerPoint slides back and forth at each other. I brought up that the
software we used at that time was
METIS, and METIS modeled all the processes, everything that was involved.
The frameworks are about creating shared understanding of what we have
and where are we going to go, and the frameworks are just a set of tools
that you have in your toolbox that most people don't understand.
Samsung
said you just hit it with a 2×4. I used to be demonstrating it, rather
than tossing out slides, here are the relationships, and be able to show
that it really works. To me that was a real demonstration that I can
even overcome some of the politics and cultural differences within
enterprises.
Brown: I want to give one more
question. I think this is more of a concern that we have raised in some
people's minds today, which is, we are talking about all these different
frameworks and ontologies, and so there is a first question.
The
second one is probably the key one that we are looking at, but it asks
what does each of the frameworks lack, what are the key elements that
are missing, because that leads on to the second question that says,
isn't needing to understand old enterprise architecture frameworks is
not a complex exercise for a practitioner?
Band:
My job is not about understanding frameworks. I have been doing
enterprises solution architecture in HP at a standard and diversified
financial services company and now at health insurance and health
solutions company out for quite a while, and it’s really about
communicating and understanding in a way that's useful to your
stakeholders.
The frameworks are about creating shared
understanding of what we have and where are we going to go, and the
frameworks are just a set of tools that you have in your toolbox that
most people don't understand.
So the idea is not to
understand everything but to get a set of tools, just like a mechanic
would, that you carry around that you use all the time. For instance,
there are certain types of ArchiMate views that I use when I am in a
group. I will draw an ArchiMate business process view with application
service use of the same. What are the business processes you need to be
and what are the exposed application behaviors that they need to
consume?
I had that discussion with people on the
business who are in IT, and we drove those diagrams. That's a useful
tool, it works for me, it works for the people around me, it works in my
culture, but there is no understanding over frameworks unless that's
your field of study. They are all missing the exact thing you need for a
particular interaction, but most likely there is something in there
that you can base the next critical interaction on.
Six questions
Zachman:
I spent most of my life thinking about my frameworks. There are six
questions you have to answer to have a complete description of whatever
it is, what I will describe, what, how, where, who, and why. So that’s
complete.
The philosophers have established six
transformations interestingly enough, the transfer of idea into an
instantiation, so that's a complete set, and I did not invent either one
of these, so the six interrogatives. They have the six stages of
transformation and that framework has to, by definition, accommodate any
factor that’s relevant to the existence of the object of the
enterprise. Therefore any fact has to be classifiable in that
structure.
My framework is complete in that regard. For
many years, I would have been reluctant to make a categorical
statement, but we exercised this, and there is no anomaly. I can’t find
an anomaly. Therefore I have a high level of confidence that you can
classify any fact in that context.
There is one periodic table. There are
n
different compound manufacturing processes. You can manufacture
anything out of the periodic table. That metaphor is really helpful.
There's one enterprise architecture framework ontology. I happened to
stumble across, by accident, the ontology for classifying all of the
facts relevant to an enterprise.
In terms of completeness I think my framework is complete. I can find no
anomalies and you can classify anything relative to that framework.
I
wish I could tell you that I was so smart and understood all of these
things at the beginning, but I knew nothing about this, I just happened
to stumble across it. The framework fell on my desk one day and I saw
the pattern. All I did was I put enterprise names on the same pattern
for descriptive representation of anything. You’ve heard me tell quite a
bit of the story this afternoon. In terms of completeness I think my
framework is complete. I can find no anomalies and you can classify
anything relative to that framework.
And I agree with Iver, that there are
n
different tools you might want to use. You don’t have to know
everything about every framework. One thing is, whatever the tool is
that you need to deal with and out of the context of the periodic table
metaphor, the ontological construct of The Zachman Framework, you can
accommodate whatever artifacts the tool creates.
You
don’t have to analyze every tool, whatever tool is necessary, if you
want to do with business architecture, you can create whatever the
business architecture manifestation is. If you want to know what DoDAF
is, you can create the DoDAF artifacts. You can create any composite,
and you can create any compound from the periodic table. It’s the same
idea.
I wouldn't spend my life trying to understand all
these frameworks. You have to operate the enterprise, you have to
manage the enterprise and whatever the tool is, it’s required to do
whatever it is that you need to do and there is something good about
everything and nothing necessarily does everything.
So
use the tool that's appropriate and then you can create whatever the
composite constructs are required by that tool out of the primitive
components of the framework. I wouldn’t try to understand all the
frameworks.
What's missing
Forde:
On a daily basis there is a line of people at these conferences coming
to tell me what’s missing from TOGAF. Recently we conducted a survey
through the
Association of Enterprise Architects
about what people needed to see. Basically the stuff came back pretty
much, please give us more guidance that’s specific to my situation, a
recipe for how to solve world hunger, or something like that. We are not
in the role of providing that level of prescriptive detail.
The
value side of the equation is the flexibility of the framework to a
certain degree to allow many different industries and many different
practitioners drive value for their business out of using that
particular tool.
So some people will find value in the
content metamodel in the TOGAF Framework and the other components of
it, but if you are not happy with that, if it doesn't meet your need,
flip over to The Zachman Framework or vice versa.
John
made it very clear earlier that the value in the framework that he has
built throughout his career and has been used repeatedly around the
world is its rigor, it’s comprehensiveness, but he made very clear, it’s
not a method. There is nothing in there to tell you how to go do it.
The value side of the equation is the flexibility of the framework to a
certain degree to allow many different industries and many different
practitioners drive value for their business out of using that
particular tool.
So you could criticize The
Zachman Framework for a lack of method or you could spend your time
talking about the value of it as a very useful tool to get X, Y, and Z
done.
From a practitioner’s standpoint, what one
practitioner does is interesting in a value, but if you have a practice
between 200 and 400 architects, you don't want everybody running around
like a loose cannon doing it their way, in my opinion. As a practice
manager or leader you need something that makes those resources very,
very effective. And when you are in a practice of that size, you
probably have a handful of people trying to figure out how the
frameworks come together, but most of the practitioners are tasked with
taking what the organization says is their best practice and executing
on it.
We are looking at improving the level of
guidance provided by the TOGAF material, the standard and guidance about
how to do specific scenarios.
For example, how to
jumpstart an architecture practice, how to build a secure architecture,
how to do business architecture well? Those are the kinds of things that
we have had feedback on and we are working on around that particular
specification.
Brown: So if you are employed by
the US Department of Defense you would be required to use DoDAF, if you
are an enterprise architect, because of the views it provides. But
people like Terri Blevins that did work in the DoD many years, used
TOGAF to populate DoDAF. It’s a method, and the method is the great
strength.
If you want to have more information on
that, there are a number of white papers on our website about using
TOGAF with DoDAF, TOGAF with COBIT, TOGAF with Zachman, TOGAF with
everything else.
Forde: TOGAF with frameworks,
TOGAF with buy in, the thing to look at is the ecosystem of information
around these frameworks is where the value proposition really is. If you
are trying to bootstrap your standards practice inside, the framework
is of interest, but applied use, driving to the value proposition for
your business function is the critical area to focus on.
You may also be interested in:
