Enterprise Architecture in Enterprise with MIS

Hi there,
Actually I'm in a muddle.As i read some useful white papers and
books(e.g. Spewak, S., EA Planning, Developing a Blueprint for
Data),I found that the most important advantages of EA are
Decision making,Integrated information systems and shared
data.However,the enterprise that has MIS has reached these
objectives.So,Is it worthwhile to implement EA for such a
enterprise?

Popular White Paper On This Topic

As business strategy needs to be a continual process, and strategy i
mplementation must be responsive to this continual change in that direction
. In addition to the goals of EA, as you have mentioned, are to provide the
flexibility for evolution and points of stability too. An Enterprise Archi
tecture strategy aims at objectively translating the business strategy into
objectives for building, enhancing, or modifying/supplementing business an
d system capabilities together with an implementation roadmap. In nutshell,
Resilience to change can be seen as a key architectural objective. Has MIS
in the(this) enterprise reached at a stage where the positioning of enterp
rise and system architecture acts as the critical link between the business
strategy ready for execution in the dynamically changing business scenario
(where the technology as well as the business practices are rapidly evolvi
ng and changing)?
regards,
akshaya bhatia

An MIS might go some way to better Decision making, Integrated information
systems and Shared data, but it certainly isn't a direct attack on the last
two. The fact that a MIS draws data from distinct systems does not mean that
those systems are integrated or share data in sense meant by Spewak.

EA should be aimed at reduced cost and increased efficiency of *ANY*
process
- not just ISS.
Just happens that IS supports the data that supports almost all business
process these days.

Turn the clock back 60 years, and we might be comparing wartime filing
systems to catalog citizens, or early-warning systems based on
sandtables and
models to show where the enemy were on a near-realtime basis as
early-warning
stations phoned, telegraphed, or sephamored there information in.

I agree your examples are same thing in that they are about data processing
systems*. And software systems are the ever expanding subset of data
processing systems that (in the digital revolution) has replaced older data
processing system of the kinds you mention.

But I don't want to drop the IS/IT emphasis - because we are primarily about
data processing systems. Most EAs report to IS/IT department managers. Many
large organisations employ other managers with a remit covering cost
efficiency and effectiveness, reporting perhaps to a COO or CIO? There may
be still be some kind of Organisation and Methods department.

I should refine the primary goals of EA with your input to become:
"Increased efficiency and effectiveness of an enterprises' business through
1 - higher quality of IS/IT support for business processes and decision
makers.
2 - faster response of IS/IT to needs of and changes in business processes
and decision makers
3 - reduced cost of IS/IT support for business processes and decision
makers.
4 - improvements in business processes and decision making through the use
of IS/IT innovations and techniques.

The secondary goals we discusss, like data sharing and process sharing,
consistency of technologies and standards, are simply means to those ends.
And perhaps, sometimes, we pursue the secondary goals regardless of the
primary ones?

Graham

* Systems that are not data processing systems (but are usually supported by
them) include manufacturing processes and human activity systems. Some
businesses are dominated by human activities. As a supporter of Newcastle
United, I wouldn't ask an enterprise architect to improve their standing in
the premier league. I'd buy better players. Consider also the arts, a
theater, a pop group, health and social services, psychiatry, education. Or
an IT consultancy business:

Hi... I have beem laying low on these discussions lately, but this seemed a good point to get confirmed we are speaking of Enterprise Architecture in the context of Information Systems, and their use of Information Technology. While it seems these dang computers are involved in everything these days, I don't think EA can do 'everything' for a business.

Could not disagree with you more on that,than suggesting that get
ting the business alignment with the use of Information systems and applyin
g Information Technology is a reality. In a scenario, where businesses run
through labyrinth of very tough competions from all directions, the applica
tion of the enterprise architect in creating robust information systems gai
ns immense imprortance.

Perhaps you should ask an Enterprise Architect to improve Newcastle United's
standing in the Premier League. After all, he couldn't do any worse than the
last four managers :o) And he'd probably stand a better chance of making a
difference than he would undertaking the academic exercise of developing an
Enterprise Architecture :o)

Very good Steve. Made me laugh. Yes indeed. Akshaya needs to worry not so
much about David saying EA (IS and IT) cannot do everything for a business
as about those within the IS and IT department - including solution
architects - who question the contribution made by enterprise architects to
the work that is done.

We're not within a million miles of answering the original question - about
how to measure the value of the enterprise architects or their strategy. My
boss asked me once. I told him "I guarantee that the productivity of our
systems integration projects will be X% bettter with me than without me, and
turnover among our architects and analysts will be Y% lower with me than
without me" knowing there wasn't a snowball's chance in hell of the numbers
being measureable. In the end, my livelihood depended on willing sponsors
and anecdotal feedback from the troops.

I dont have any doubt in my mind about paramount importance of
the role that Enterprise Architect plays in creating the guidelines for IT
/IS solutions in alignment with the business processes. I feel that some VI
Ps (very intelligent professionals) tend to belittle this role inadvertentl
y because,may be, they have come accross some cases where the lacunae in th
e technology oriented business systems has resulted in them putting the bla
me squarely on the Enterprise Architect fairly or unfairly.

regards,

akshaya bhatia

On Tue, 27 Mar 2007 GrahamBerri via enterpr
ise-architecture-sp wrote :
>
>
>Ve
ry good Steve. Made me laugh. Yes indeed. Akshaya needs to worry not so muc
h about David saying EA (IS and IT) cannot do everything for a business as
about those within the IS and IT department - including solution architects
- who question the contribution made by enterprise architects to the work
that is done.
>
>We're not within a million miles of answering the orig
inal question - about how to measure the value of the enterprise architects
or their strategy. My boss asked me once. I told him "I guarantee that the
productivity of our systems integration projects will be X% bettter with m
e than without me, and turnover among our architects and analysts will be Y
% lower with me than without me" knowing there wasn't a snowball's chance
in hell of the numbers being measureable. In the end, my livelihood depende
d on willing sponsors and anecdotal feedback from the troops.
>
>
>--

1. We surely all agree architects are important in aligning IS/IT solutions
with business processes.

2. No doubt enterprise architects guidelines can help solution architects
align IS/IT solutions with business processes. However this has always been
the raison detre of the solution architect and the whole solution
development team, so it would be great if you could give us examples of
where enterprise architects' guidelines have proved paramount in achieving
this alignment.

3. The thing David and I were challenging was the idea that the enterprise
architect is responsible for the effectiveness of the business processes
themselves (not the IS/IT support for them). e.g. responsible for the
position of Newcastle United in the premier league, or Shell among Oil
Companies. There is only so much IS/IT solutions can do - and there are lots
of other people - business managers - who are more directly responsible and
accountable for the business processes themselves.

But its about the information systems, right? What I am saying is that having an Enterprise Architecture itself is not a business benefit, it dosen't automatically raise sales or anything. EA is a blueprint for the Information Systems that will assist the business in raising sales...

Wrong. It's about the "enterprise". Isn't that what the "E" in EA stands
for?

"What I am saying is that having an Enterprise Architecture itself is
not a
business benefit, it dosen't automatically raise sales or anything."

Agreed. It's the application of it that provides the benefits. And
that's
where every organisation I've seen who has an EA fails. The production
of
the EA is an academic exercise and there is never any practical use of
it.
That's not to say there can't be. I've just not witnessed it in 10+
years in
EA.

EA is a blueprint for the Information Systems that will assist the
business
in raising sales.

Errr. Wrong again. This is ony part of it. EA is not just IS. It's about
the
"enterprise". So it's the business - what it's trying to do, how, with
who,
how they are organised etc. as well as the IS/IT to support the
business.

Maybe we need to invent a new acronym EISA or EITA = Enterprise IS or
IT
Architecture. Then we can just talk about IS/IT stuff and ignore the
business :o)

Mad idea. Or maybe not. I can give you real examples of where I've seen
this......

Consider this:
For the entire enterprise, in increased sales or reduced support costs
might
be difficult to measure.
However, if you take a number of internal organisations (IT, ISS,
project
office, process improvement group, etc) then the value propostion and
reduced
time-to-market is clear.

However, 'Enterprise
Architecture' is not a 'thing'. It's a process, which is why you employ an
Enterprise Architect to drive it.
If your write up an EA blueprint &
roadmap and leave it at that, everyone will put it in their shelves and smi
le at it contently. And then it will fail spectacularly.

Part o
f doing EA properly is to develop a governance process that formally links
in to the program management processes controlling your projects.
At m
y company, that means assessing every BUSINESS project for architectural si
gnificance (ie whether it contributes to, influences, detracts from, or alt
ers the architectural vision). If so, it must be assigned a solution archi
tect (may be part of someone's role) who is responsible for ensuring the EA
blueprint is considered.
Then, even if the project goes against the t
enets of the blueprint (too expensive, unable to convince people, too lazy
etc), it was a DELIBERATE and DOCUMENTED decision. Also, going against the
blueprint is effectively going against the business vision & strategy, upon
which is based and closely aligned...

Another part of EA govern
ance is tracking benefits realisation. This involves taking a hypothetical
view of what the project would cost if you didn't follow the EA blueprint,
or you weren't making use of something provided by a previous EA-aligned pr
oject.
This is necessarily after-the-fact, and as such can produce som
e rubbery figures based on hypothesis. However, it's still a valid way to
measure and can be independently verified if anyone is skeptical. After all
, all the EA-related decisions were documented...

All I can say
is that it works in my company, and having an EA (process, not thing) has a
lready saved us over half a million (measurable) dollars inside 18 months o
f it's operation. Not bad for something aligned to a 5-year vision. Still
got 3½ yrs to run and the big projects haven't been delivered yet...

So - forget 'building an EA'. Develop an EA process instead. Oh - and us
e a business-savvy person to run it. Not some tech-savvy IT jock.

You're off on one there and a bit out of order. I suspect some confusions,
red herrings and crossed wires are clouding the accuracy of David's point,
which I fully support.

For a start, I'd better spell out EA as Enterprise Architect (the role) or
Enterprise Architecture (the documentation of the structure at a particular
state) or Enterprise Architecture Process (by which the state is changed).
Because those three things are getting confused.

David is perfectly right to say "a [target] Enterprise Architecture is a
blueprint for the Information Systems [and IT systems] that will assist the
business". David didn't say the Enterprise Architect can or should ignore
the business organisation or business processes. He didn't say an Enterprise
Architecture can or should have no business dimension. We all say the
Enterprise Architect must understand and meets business needs. Surely that
is so elementary it is even worth saying in this group? But let us enjoy you
examples please:-)

In the main, the business people who drive business change have never heard
of Enterprise Architecture. In the main, Enterprise Architects drive
changes to IS and IT systems. Most use an Enteprise Architecture process
and/or an Enterprise Architecture to help them to a greater or lesser
extent. It works for some. It usually works in tactical way rather than the
strategic way presented in TOGAF and Zachman.

I can't remember anybody saying anything to which your "production of the
Enterprise Architecture is an academic exercise and there is never any
practical use of it." is a reply. My experience is *mostly* similar. But
even you'll surely have to backtrack a little - consider for one - the
canonical data model of an integration broker.

What's the market tell us? Who does the EA report to? What department of the
enterprise do they work in? What do the EA job adverts and job descriptions
say? What skills and experience is an EA expected to have? I've studied the
answers to some of those questions. Take the last question about skills and
experience. You'll see a lot of: IS/IT Strategy development and governance,
Technology watch and assessment, SOA, TOGAF, Zachman, J2EE, .Net,
Integration technologies. You won't see any of: finance management, sales
and marketing, product design, business management, MBA, etc etc. That's a
measure of how deeply embedded in IS and IT the Enterprise Architect (not
Enterprise Architecture) is.

Put is simply, Information system Architecture for an Enterprise, Er
go, basically an Architecture for information system based on the criteria
of alignment of the business processes with information systems and providi
ng the guidelines for Information systems and IT infrastructure layout,oper
ations and management. Dentist is a doctor specialized in treatment of teet
h and Gums. Will we dispute that Dentist is less of a doctor than say a phy
sician? Why is such an issue if some of the EA endeavors have failed to liv
e upto expectation? Surely EA is a blueprint for the Information Systems wh
ich does not mean it is just an academic exercise. If that was so, Numerous
reputed software companies would not have hired the Enterprise Architects.
The Enterprise Archtiects have even major though not implicitly perceptibl
e role in developing the software tools and software development environ ot
herwise you would not expect the creation of innovative Service Oriented ar
chitecture itself. If you look into popular J2EE-Java or DotNet software de
velopment frameworks you could even find lot of APIs in their libraries ena
bling providing E-commerce interfaces.

You have intrigued me with the statement that "The produc
tion of the EA
is an academic exercise and there is never any practica
l use of it."
I'm hoping I've misinterpreted what you're saying, so ra
ther than
responding off an assumption, can you please explain? I s
uspect this
may come down to the whole 'value of EA' question that sta
rted this
thread.

Graham,
Please check on this. Good Qs and As.
www.infosys.com/services/systemintegration/NofirmhasfailedinEA.pd f
And also on this
Anothe
r useful link, (not really in context but useful)
http://www.goobiz.com/How_to_align_IT_using_UML_and_according_to_BMM. htm
What are user views on
Goal Driven SOA?
Is it nearer to the concept of EA?

I will surely gi
ve you examples of the cases of the enterprise architects' guidelines have
proved paramount in achieving the alignment
with the business in my subse
quent post.

>You won't see any of: finance management, sales and marketing, product
design, business management, MBA, etc etc. That's >a measure of how
deeply
embedded in IS and IT the Enterprise Architect (not Enterprise
Architecture)
is.

That's not a reflection on what an EA-type person *should* be, but what
is
being asked for by (often clueless) recruiters.
It possibly a reflection of the fact that EA's are being recruited by
the IT
department, who automatically assume that reverse engineering the
current
tangle of current systems, application, and data, will somehow then
reflect
business reality.

Bizzarre.

I couldn't care less is an EA knows anything about .net or J2EE that's
what
coders and developers are for - the EA simply needs to know enough to
understand what is or is not possible, that's all.

Consider a top-class racing driver - he's not a wizz-bang mechanic, but
if he
took his own car in the shop, he'd know enough to tell when the shady
mechanic is spinning him a yarn...

1) Yes - Enterprise Architects are recruited by IS/IT departments.
Enterprise Architects do not sit on the board. They do not make
recommendations to business managaers that do *not* involve IS/IT.
Enterprise Architects are only engaged by business managers to address IS/IT
concerns. These are the facts of life. What David said was right.

2) Yes - most IS/IT departments assume that reverse engineering the current
tangle of business processes, application, data and technologies will
produce a specification (model if you like) of how things are structured and
related that reflects the state of the enterprise as it is today. It is not
a strategy. It is not specification of a future state. It does have some
value in its own right.

Point 2 is irrelevant to point 1. The confusion arose when Steve twisted his
attack on David's point into attack on Enterprise Architecture
documentation. I have some sympathy for that, and my own architecture
methodology is very carefully worded in what it says about architecture
repositories. But this is completely different discussion.

The analogy of city planning to EA in a ref document provided in a post
earlier, is, I think, a good one.

Sure - city planners need to know where utilities run, who provides the
service that "flows" in these utilities (water, power, sewerage,
foot/road/rail traffic, etc etc) who consumes them, how they should be
charged, and so forth.

Unless you have an extremely centralised economy (and not too many of
those
left!) no-one would suggest that they dictate where people live, how
they
commute, where they work, and so forth.

However, in setting mid-term policy, the city fathers (read: Board or
exec
committee) that fails to consult their planning department is making a
big
mistake.

Equally, anyone who suggested that city planners be hired by, and fall
underneath the department of transport (only) or Waste Disposal (only)
would
be laughed out of town.

I hope this analogy helps to explain why I am somewhat more focused on
the
business architecture, information(and data) architecture, rather than
systems or infrastructural architecture.

Hi All, I am of the opinion that two roles in an Enterprise are being
discussed but the same term is used for both...Enterprise Architect. The
information in point 3 is important and my understanding is encapsulated
in this modification of Graham's statement.

1. We surely all agree that IS/IT Architects are important in aligning
the IS/IT Architecture with the Enterprise Business Architecture (EBA).

The EBA (one component of which is the Information Architecture) forms
the central plexus of the Enterprise and serves as the singular
reference for the development, integration and balancing of all other
architectures...IS/IT being only of the other architectures. So the
IS/IT function still needs to develop an enterprise view of the business
from an IS/IT perspective that is appropriate in its support of the EBA.
The Enterprise Architect operating from the (for want of a better term)
business strategic perspective (usually in the Policy & Planning
function of the Enterprise) develops the EBA.

Alignment is attained by the integration and balancing of the
Capability, Performance (two more components of the EBA) and the IS/IT
Solution architectures. The integration is driven by the imperatives or
business rules contained in the Performance Architecture which constrain
human behaviour and informs machine (IS/ICT soultion) behaviour. These
imperatives have been abstracted from the strategic perspective through
to the fulfilment perspective as part of the development of the EBA.
IS/IT use this to derive and define the IS/IT system "business rules"
that must be catered for in the IS/IT Solution Achitecture.

Management of the Enterprise from the perspective of management of the
Value Streams within which Business Process Aggregates reside, as
opposed to management of the Business Processes, allows for the
balanced management of activities, outputs and outcomes that is in
alignment with a hierarchy of objectives and outcomes contained in the
Performance Architecture.

Suppose you focus entirely on business, information and data architectures.
Should the board consult you about all changes to the business? or only
those that affect the information or data architecture?

Hi All, I am of the opinion that two roles in an Enterprise are being
discussed but the same term is used for both...Enterprise Architect. The
information in point 3 is important and my understanding is encapsulated
in this modification of Graham's statement.

1. We surely all agree that IS/IT Architects are important in aligning
the IS/IT Architecture with the Enterprise Business Architecture (EBA).

The EBA (one component of which is the Information Architecture) forms
the central plexus of the Enterprise and serves as the singular
reference for the development, integration and balancing of all other
architectures...IS/IT being only of the other architectures. So the
IS/IT function still needs to develop an enterprise view of the business
from an IS/IT perspective that is appropriate in its support of the EBA.
The Enterprise Architect operating from the (for want of a better term)
business strategic perspective (usually in the Policy & Planning
function of the Enterprise) develops the EBA.

Alignment is attained by the integration and balancing of the
Capability, Performance (two more components of the EBA) and the IS/IT
Solution architectures. The integration is driven by the imperatives or
business rules contained in the Performance Architecture which constrain
human behaviour and informs machine (IS/ICT soultion) behaviour. These
imperatives have been abstracted from the strategic perspective through
to the fulfilment perspective as part of the development of the EBA.
IS/IT use this to derive and define the IS/IT system "business rules"
that must be catered for in the IS/IT Solution Achitecture.

Management of the Enterprise from the perspective of management of the
Value Streams within which Business Process Aggregates reside, as
opposed to management of the Business Processes, allows for the
balanced management of activities, outputs and outcomes that is in
alignment with a hierarchy of objectives and outcomes contained in the
Performance Architecture.

It is also important to recognize that an "enterprise" is also a
process, by
definition - specifically an "endeavor" (i.e., purposeful activity).

I encourage this group to continually push to broaden their vantage
point on
EA - it has never been just about IT. The IT function (a support
function
for all in-house IT, and the production function for an IT business) was
just the first functional, or domain, namespace to begin management,
typically of system designs and investment choices, using an EA approach
In
a similar way, an online phone-book was the first namespace to be
managed by
X.500 and then LDAP namespace management technologies - which are now at
the
heart of all networked management and security functionality. I
personally
used my company's early EA approach from 1982 through 1985 to reorganize
and
rejustify the mission, staffing, position-descriptions, structure,
resource-processes, management controls, equipment, locations,
facilities,
and budgets of a 16000 person military organization, and only then used
it
to justify the first computers, LAN/WAN, software, and related training
for
the command, along with a classified facsimile network.

When you create a map (or model) of the endeavor/process, you are going
to
have a large collection of "things", a lot of "relations" between the
things, and a lot of attributes about those things and relations. This
map
or model representing the endeavor's process (with as-is, to-be, and
transition states) is an "architecture". Hint, you'll need technology
that
can aid you with the modeling and storage/sharing/integrating of the
ever-evolving and increasingly-integrating models.

The endeavor's things are nouns and noun-phrases arrayed along the
endeavor's process (process = functional-flow arrayed across
functional-activity performers); relations are verbs and verb-phrases
(including flow relation-types); attributes are literals such as numbers
and
codes, reference/lookup noun and verb terms, narratives, other parts of
speech (POS), and binary or other objects.

So an enterprise architecture is an "endeavor process model". And
abstracting this one level higher, the "EA process" is the process for
discovering, developing, using, deploying, and maintaining one or more
"endeavor process models". EA can be focused on a single endeavor's
process
model in isolation, as multiple models that have specified
relations/interfaces, or as all endeavor process models in a
unified/integrative/federated namespace with discovered/dynamic/evolving
relations/interfaces known as a value-chain, or in my terms, a
value-lattice.

My organization calls our template for this unified endeavor process
model
namespace the "general enterprise management" (GEM) approach. GEM dates
back to the early 1980's, with its conceptual roots going back to the
1950's
and our early general object models and subsequent general
knowledge-models.

Let's just say that (if!) I am the guru or all EA-types, *and* have a
firm
control over BA, IA, and DA parts of the business, then:

The board should not consult me - I should have sufficient governance in
place what whenever someone touches "my" architecture, I have a chance
to put
my say-so in (and by "my", I'd usually mean a team)

So if the board were considering a major acquisition, or re-structure
(e.g.)
then I should be there, advising on what this means to the above
architectures. Not saying "no" mind - simply telling them what this
means. I
can think of several M&A's that have failed to pay expected dividends
because
this has not occurred.

All changes to business, because they affect context, always affect IA
and
DA.

BA>DA>IA>intelligence>stragety

The extremely expensive consultancies that deal with 9-figure deals,
know all
this, and try and fast-track with "clean-room" teams and similar to get
a
somewhat high-level idea of all this...

I believe that the focus should be in always and constantly maintaining
the optimal IS/IT Architectures in support of the Enterprise Business
Architecture (EBA). All changes to the business are reflected in the EBA
and by virtue of the fact that it is the single reference point for the
development of the Architectures that support it, changes that are made
to business by business, will trigger the refinement of all the support
architectures. I believe that the Board should engage with the strategic
planners of IS/ICT (among others, in an integrated manner) around the
business outcomes that need to be achieved so that they can apply their
knowledge and suggest ways that the application of IS/IT (automisation
of functionality and also the impact of provision, support and
maintenance of automated functionality) can be wielded to yield
competitive advantage. This input, by its nature, presents the Board
with an opportunity to refine its original premise and to carry these
through to the changes that it needs to effect.

In our approach, Policy & Planning has overall responsibility for the
EA. It develops the Enterprise Business Architecture (EBA). It is also
convenes a committee that comprises strategic planners and architects
from the specialised areas of the organisation eg. IS/IT. This committee
is responsible for co-ordinating the integration and balancing of the
various architectures that support the EBA. We do use MBA types to
develop the EBA. All supporting architectures are developed by the
specialists within their area of specialisation.

I think they ought to.
From a business architecture side, this is nothing new.
It's only from the late eighties and early nineties onwards that the
predominance and pervasiveness of ISS, data, and IT-*enabled*
information
flow became so overwhelming, that it got handed over to IT departments,
who
said;
"huh? Wot? So you want to see an ERD or something?"

So now the techies have woken up to something new - and as we like BPM,
modelling of all sorts, etc, they (we?) have picked it up with a
vengance...

You can stop worrying about breadth of scope. Nobody in this group has ever
suggested EA is just about IS or IT. What David and I said was that in
practice, Enterprise Architects steer IS/IT and its support for the
business, rather than steer the business itself. Some people simply misread
what we were saying. We were talking about power, influence and purpose more
than documentation.

But do worry about depth of detail. There are some in this group - me
included - who doubt the practicability of documenting the enterprise's
architecture (any aspect of it business, IS or IT) in great detail. I asked
you a week or few back whether in practice your repository records not only
the strategic-choice technologies, but all the uses of those technologies.
Can you tell us?

>Hi, Graham
>
>I believe that the focus should be in always and constan
tly maintaining
>the optimal IS/IT Architectures in support of the Enterp
rise Business
>Architecture (EBA). All changes to the business are reflec
ted in the EBA
>and by virtue of the fact that it is the single reference
point for the
>development of the Architectures that support it, changes
that are made
>to business by business, will trigger the refinement of a
ll the support
>architectures. I believe that the Board should engage wit
h the strategic
>planners of IS/ICT (among others, in an integrated manne
r) around the
>business outcomes that need to be achieved so that they ca
n apply their
>knowledge and suggest ways that the application of IS/IT
(automisation
>of functionality and also the impact of provision, support
and
>maintenance of automated functionality) can be wielded to yield
>
competitive advantage. This input, by its nature, presents the Board
>wit
h an opportunity to refine its original premise and to carry these
>throu
gh to the changes that it needs to effect.
>
>Regards
>Mohamed Khan

Regarding your enquiry: "whether in practice your repository records not
only the strategic-choice technologies, but all the uses of those
technologies", I must have missed that email.

Do not confuse the knowledge of the EA approach (i.e., intention,
concept,
methodology, metaschema, supporting-technology criteria, and then
implementation/operation/maintenance using various technogies), with the
specific technology (i.e., repository) implemented/operated/maintained
to
support EA.

The EA approach design includes the capability-design to record
"strategic-choice technologies" and all of the chosen-technology uses.

>From my experience, some EA modeling tools and repositories will support
this recording of "choices and uses", and some will be hard-pressed to
do so
because of their choice of underlying object-model.

I love a good analogy as much as the next person, but once Scott Adams introduced the "analogy police" in Dilbert, I try to avoid them or use them judiciously.
I remember having arguments with a former co-worker about the merits of top-down planning ala Information Engineering and its Architecture, and he would say that it smacked of communism (his favourite analogy), where total planning as a system had failed. I think what people forget is that we do live, and companies operate, in a market-driven capitalist economy where infrastructures exist to support all that un-planned interaction; however, each company making its way in the economy is not a mini-economy itself, its a dictatorship. My co-worker seemed to believe because he ran a department and had a budget, he could do anytrhing he wanted. At the time the favourite thing to do was to ignore IS and buy a package , hire some of your IT folks and try doing it yourself. Now, centalization and de-centralization is pendulum for which a company will find its balancing
point, but it is not 'market-driven'; someone will decide that departments can't spend their budget on just anything they want, for example.
The other thing is that comparing information systems to physical items like town planning or building a house is fraught with danger. It has been suggested that while all physical tools or edifices are extension of mankind's physical strength and or protection for our frailities, Information Systems are an extension of the brain, of thinking (I will forward the quote when I find it again). The nature of Information Systems is just different from any other asset or resource a company can wield, so we should keep that in mind when an analogy springs to ones' mind.
Oh, and a little 'spice' in these conversations is great, you can say things here (within reason) that can't be said in your day job, for example. So carry on!

I have been to that EBA site before, reminds me of James Martin's extension of Information Engineering into 'Enterprise Engineering'. (where is James these days, anyone know?).
Given all its points on the main page about being business focussed, it still ends up speaking to IT Architectures; nothing wrong with that, but I am just trying to recall hearing any CEO speak about their EBA(!).

Why would CEO's have a need to speak about EBA, they are concerned with
numbers and general management with their number 2's... As you said in your
previous message, your friend had the department and the budget, he ran the
show (for that area)... it is these business types you will find on the
boards making the decision regarding the actual processes (architectures) of
the business... and it is to them that an 'Enterprise Architect' will
advise, regarding both Business AND IS/IT...

A search on GEM lead me to http://www.one-world-is.com/beam/Is this the GEM you are talking about?
(Reminds me of side-story: My son was involved in a high school production of the 50's broadway musical 'The Pajama Game', which became a Rock Hudson and Doris Day film, I think. Anyway, its about the trials and tribulations of those working at a factory that makes pajamas. One of the featured characters is what I would call a 'time and motion study' expert, his big song is about measuring everything and reducing it all to the shortest possible time. When I heard this song the night I attended, my brain automatically thought Business Process Management! and Six Sigma!)

Curtis,
"As you said in your previous message, your friend had the department and the budget, he ran the show (for that area)..."
... but such Managers can't do anything they want, especially with SOX auditors hanging around. Its a real problem, for example, when two different managers end up doing the same thing without knowing that the other one is doing it too.
" it is these business types you will find on the boards making the decision regarding the actual processes (architectures) of the business..."
... but a board or a senior management team is not a democracy. The chairman or CEO has to make the final call.
" and it is to them that an 'Enterprise Architect' will advise, regarding both Business AND IS/IT..."
Well, maybe in Mohammed's company, but I have never seen it.

Has anybody out there ever known an enterprise architect advise the CEO or
his/her business managers on business matters per se?

(Business matters per se excludes the IS/IT support for the business. It
includes matters like business service innovations, pricing, product design,
staff recruirement policy, staff incentives, management structure, business
locations. It includes business process improvement or reeingineering OTHER
than that forced on the business by the acquisition of IS/IT solutions.)

Definitely not.An enterprise architect has no business to advise
CEO or the enterprise's executives on their business matters.The role of an
enterprise architect is only to provide architectural roadmap of IS/IT dep
loyment based on the business architecture of the enterprise which would in
volve at first stage, creation of direction-setting document based on an in
-depth study of the strategy of the organization, its business processes an
d the technology best suited practices. Furthermore, the architectural road
map could be based on identification of gaps between the current architectu
re and the architecture vision.EA can assign or suggest priorities to fill
the gaps, and provide guidelines on resource usage to staff/prioritize the
projects. Based on the business model,EA can categorize the components of a
technical architecture which could cover the tools, techniques and methodo
logies used to build IT/IS infrastructure.In nutshell EA would address to c
reating guidelines for IS/IT infrastucture based on business model of the e
nterprise encapsulating the data,operations,security and application develo
pment aspects. Business matters are solely in the domain of the Enterprise
's TOP management and the executives who are the owners and drivers of thei
r business processes. But, practically speaking, do business matters really
exclude or can ignore IS/IT support?

Mohamed, not to be unpleasant, but perhaps we are mis-communincating on
some
finer points of english language:
"should" or "ought"?

I would accept "ought to", but fact is, most management teams do not
have a
single technology person on them, never mind an intergration-type VP who
can
promise to deliver certain capabilites.

Another fact - even in tech-heavy companies, less than 5% of board or
CxO
level people have a tech background - even the split of backgrounds of
CIO's
reveals a huge number from non-technical areas (as it should be - but
CxO
other areas do not show a similar number of tech-background people in
their
demographics)

So I warn about audience - talk like this to a CxO group, and you're
going to
get ignored at best.

I personally love analogies, parables, and metaphors.
Sure, they're full of peril, and only stretch so far - map is never
territory.

One of the reasons I like them (and one of the reasons they break down
with
groups such as this, with a certain slant of mindsets - call them INTJ's
or
INTP's if you like Myers Briggs) is that they are models.

They simplify and abstract.

This is both good and bad, and runs the risk of an abstraction being
valid
for two totally different concepts (heck, look at the abstraction "EA"
as a
verb, or one of two nouns in just the English language!)

Now we can all nit-pick, and split semantics, but I personally would
rather
listen carefully to get at what each of the posters is trying to tell me
-
I'm sure they would not be taking time to share if they did not feel
there
was value.

One your second main point:
It's truly difficult to relate what happens inside a business to
macroeconomics - as you say, analogies are dangerous.
Still and nonetheless, I believe that considering an EA persons' role as
a
town planner in either a service-driven market economy, or a
centrally-led
and planned one makes some sense.

I feel that those people who believe they can buy and implement whatever
tactical solutions their department needs, are actually more
"communist/socialist" than market-led. Someone has given them a budget,
and
they are hell-bent on spending it. One sees this a heck of a lot in
public-sector industries everywhere, and even in private sector.
I await the wide adoption of zero-based budgeting...:(

As to your last significant point:
"info systems are different to any other resource a company can wield"
True, as far as it goes - they are the custodians and conduits for the
companies short and long term corporate memory.
Perhaps we should recommend that grounding in psychiatry, psychology,
neurobiology, and some AI is a pre-req for even starting to talk about
EA?

:)

Nic Harvard

PS: If you thought I meant the last remark in complete seriousness,
think
again. If you thought it was a *complete* joke, however, go away and
think
some more.

Thanks William.
Interesting resource.
MS Motion swings the pendulum back from business process modelling to
business function hierarchy (1980s Information Engineering)
As it happens, I sometimes work with Microsoft's leading Enterprise
Architect in Europe.
I bet you - he has never head of this!
I'll let you know.

Specifically, City Planning is a highly dubious analogy for Enterprise
Architects to use. French Enterprise Architects love this analogy because it
has cultural resonances for them. 18th/19th century Paris and all that. What
they don't tell you is that Paris was set out in a plan with long, strauight
and wide boulevards for a very specific reason - so that cannons could be
used to quell any rebellion by the populace against the dictator. Ah ha! So
it is a good analogy for Enterprise Architects after all.

Generally, an analogy is a device by which a speaker makes a proposal,
promise or threat about reality against which reasoned argument is
impossible - because it is clearly true in the analogy. If the listener
refuses to engage with the analogy he/she is seen as a spoil sport. The best
counter is to return with a different analogy leading to the opposite
proposal, promise or threat - provided a) it is better than the first
analogy and b) you can do it fast enough. So my counter is this. Enterprise
Architects are like Doctors. Quasi professionals pretending to be
scientists.

Here is a link to a powerpoint presentation defining motion and which
could be of some help to understand the principles
Of Business architecture:
http://www.ronjacobs.com/Slides/1_Motion_060118.pp tRic Merrifield and his team are building a very comprehensive,
straight-forward and logical vision of
Business architecture and its IT/IS Layers.

What you have written (correct me if I have read it incorrectly) sounds like
a contradiction to the first comment "Absolutly not"...

then you write:
"at first stage, creation of direction-setting document based on an in
-depth study of the strategy of the organization, its business processes
and the technology best suited practices"

This to me is what I would call creating artefacts for 'advising' the topics
of the EA strategy.

---
While I am here if I can make another remark concerning CEO's number 2
managers... yes they do have there business to run and manage that has
nothing to do with EA, BA, SA etc. When they get together, it is not only
for general board/group meetings regarding general business, there are also
other more focussed 'gatherings' based upon how they support their business,
and no it is not just about IS/IT, this can go into such things (as Mohammed
has mentioned) Planning, Policy, Governance, Resources (people), and
process(/service)... these meetings do take place with EA (the person) being
available for advise (not decisions) based on the EA (the arteface)...
Just to re-state, these meeting don't usually include CEO.

" MS Motion swings the pendulum back from business process modelling to business function hierarchy (1980s Information Engineering) "
Oh my, deja vu or what. Everything old is new again? Check back in a year or so and it will probably now have "Business Capability Re-Engineering"!
Seriously, nothing ike a good functional decomposition/hierarchy for breaking a business domain into its component parts. Then match that decomp to a subject area decomposition and you have something going, ala 1987.
Granted, Information Engineering only focused on data and function and their interaction, just two of Zachman's columns, but those are still the columns with the most 'stuff' in them, so a little IE can go a long way in EA.

Your assertion "board/group meetings do take place with EA (the person)
being available for advice (not decisions) based on the EA (the artifact)"
is interesting but less informative than we could hope.
Is this
a) your belief about what should happen if the EA function is working
properly?
b) your knowledge of what does happen in the business you work in?
c) your knowledge of what happens in several businesses?

You don't have to name the businesses, but I think we ought to know which of
these applies.

Hi everybody,
what a great discussion.
Graham,
As you said,everybody who wants to implement EA should be worry about depth of details.Actually,it's one of the factor
that can make your project fail.More deatails,more time,more money.As you know, we should consider that based on our visions and objectives
But me myself have some problem in this case.Suppose that you objective for implementing EA is "better alignement between Business and IT"
,Do we have any metrics for determining depth of details ?

I would say again definitely not, on whether this wa
s an contradiction.
Perhaps, I was misconstrued. My first statement of in
reply to a post that whether EA advise the CEO on how the (his) business s
hould be run, and answer to that is surely no. Subsequently, I delved upon
the role that EA undertakes while taking the base from the enterprise's exi
sting business processes,it's strategy and it's vision for the future to cr
eate the technology/systems guidelines/arifacts. Considering the base of th
e EA's endeavour, you can derive that function of EA is not normally to adv
ise albeit as a professional or like any body else associated with the ente
rprise he can advise informally.Planning, Policy, Governance, Resources,Man
aging business processes and resources are not in domain of an EA but the M
anagement of the enterprise.I hope that you don't find any contradiction in
this.
regards,
akshaya bhatia

Yes. I did, when I was the equivalent of the CIO and EA for a large
military organization in the 80's. In that case, EA was known as "Force
Structure Management" and "Manpower and Equipment Management", which are
standard Army terms, with equivalent approaches in the Air Force (Management
Engineering) and Navy (Efficiency Review). Other related DoD terms are:
"Table of Organization and Equipment" (TOE), Modified TOE (MTOE), and "Table
of Distribution and Allowances" (TDA).

There are thousands of folks in DoD who know how to do modern EA, and have
done what you've enquired about. The "modern" EA movement is just calling
it by a different name, focused on different resources.

You have a knack for answering a question you want to answer rather than the
question as it was intended!

I'm interested (for professional reasons) in the facts of the real job
market - in what is done by people who are employed with the job title
"enterprise architect" . Not in what is done by people that you or I might
like to *call* enterprise architect, since that creates a circular argument
in which opinions are presented as facts.

Try to keep this reply short, as there has been some good discussion
already...

a)'my belief'
Advice whether it is in the form of documents, models, diagrams or verbal
for any area of a 'business' whether it is business or IT is just that...
advice. However presumably this advice is based upon 'best practice',
standards, methodologies, policy and analysis etc, the creation of this
'advice' is what I believe an EA should be responsible for... example, just
because an architect designs the worlds best application framework (or the
best organisational working/informational structure) does not mean a
business manager (whether it be CxO or other) is going to 'decide' to go
with it, it is up to the EA to 'advise' on benefits, risks, potential costs
and time (+ other such as strategic positioning), for a more informative
decision to be made.

b&c)'my knowledge'
I am a consultant and have worked in a number of different types of
organisations. Within these different organisations various different models
of the concept of a board occur (center of excellence, architectural board
etc), however where EA is concerned for these management team meetings usual
surrounds strategic planning/alignment/discussion. These are by no means
regular get-togethers (and in my view nor should they be), depending on the
org. usually 6-12 months. Where the architectural discussion for business
and the greater IT issues are discussed and future 'direction' decided upon
(this includes, but not limited to discussion around organisation structure,
teams, departments, application, information, and infrastructure) and allows
for cross silo communication and focus.
The EA's will give advice as to there view to the 'best' approach and the
managers will decide based on the facts/design/time/costs where to go. The
decisions become policy and filter throughout the organisation (where
required). This is where the departments make use of the high level policy
and IS/IT can continue their tasks based upon their part of the
architecture, the decisions are know on the departments or internal teams to
make based upon their requirements, as long as they follow policy.
Note: I am not referring to a general company Board Meeting that also
occurs, but a board-like structure where the management team talk about the
business infrastructure (just so happens that IT is part of that business
infrastructure).

Ah, but what happens when there needs to be a tactical change done quickly
that affects the EA in policy, and the next meeting for architectural
decisions is not for another 6 months, well firstly things don't move that
fast and secondly a good policy to have for EA is a Organisational Change
Management policy which covers just such an emergency, however this still
needs to be managed/signed off/approved by the management team (through less
formal methods)...

This is still a very abstract description, there could be (and has been)
'thick' books written on the topic.

This is just a humble view from a humble consultant trying to do a
not-so-humble role.

Thanks. I call my earlier response positioning, at which you also have a
knack.

As to those EA who advise CEOs and business managers outside of IT, look to
the Federal Government. The Federal civil government activities are now
pursuing business transformation and segment/domain/capability/function
improvement using EA as the foundation. As desribed in my previous response
to your query, DoD has used an EA-predecessor approach for decades to
support/advise executive-level management and non-IT functional managers.

Many of the Federal Agencies and Bureaus that have moved farther along in
implementing their enterprise architectures do seek and accept consultation
and advise from the enterprise architect. Department of Interior (DOI)
comes to mind as a good example, where they use their enterprise
architecture to advise and support business transformation. Look for those
Federal Agencies and Bureaus that have received a higher rating of 3 through
5 on their EA Assessment Framework (EAAF).

> market - in what is done by people who are employed with the job title
> "enterprise architect" .

Here is a sample, hope good for discussion:

The Enterprise Architect will be able to provide architectural designs and
solutions that are based upon an enterprise federated model that is across
the globe, create architectural vision for service solutions, processes and
innovative ideas.

Must be able to articulate and properly communicate architectural solutions
to teams of technical and non technical staff and be able to do problem
anticipation and problem resolution for aligning operating group strategies
to the Enterprise Architecture Practice.

Define and determine capabilities and have architectural domain knowledge
for all types of architectural solutions that include enterprise services,
middleware services, portal services, enterprise service bus, application
integration, architectural infrastructure services, and other technical
solutions that align to various business requirements to name a few.

- Serves as individual contributor and has leadership ability in being a
visionary to senior EA management as well as IT Operations, operating
groups, technical staff, project management and client(s) and will interface
across several channels to proactively assist in defining solutions,
direction, specifications and architectural principals representing
Enterprise Architecture Practice on project initiatives and/or project
development.

- Functions as change leader and change agent representing the EA Practice
while coordinating with operating groups on solution designs by leveraging
technology, combining solutions in innovative ways, by being proactive in
recommending required solutions and courses of action that align to business
goals for maintaining cost effectiveness, competitiveness and performance
objectives.

- Remains continuously aware of business needs, technical directions as well
as infrastructure capabilities and acts as sounding board and consultant to
facilitate development of solutions that align to current and future
architectural strategies by analyzing business requirements and their
relationships and dependencies to, operating groups, IT Operations and the
Enterprise Architecture Practice.

- Defines architectural solutions for using enterprise services, application
system solutions, technical infrastructure integration, and in some
instances, business systems architecture for projects either being planned
or are currently under development.

- Provides input into enterprise technologies and solutions as well as
maintaining architectural portfolio management that is used for strategic
planning for the Enterprise Architecture Council.

- Analyzes architectural requirements from operating groups and maps
technologies to specific enterprise architectural standards in order to
align to strategic design concepts that are cross functional and cross
platform for enterprise interconnectivity. - Applies Enterprise Architecture
Practice's vision and strategies to all operating groups for defining
capabilities for all enterprise projects. Communicate best practices and
goals on different architectural models that are consistent with Carlson's
Score Card and EA Practices business strategy.

- Conducts feasibility studies and documents findings on strategic and
tactical plans and proactively assists in defining direction for future
projects and solutions. Conceives of practical architectural solutions,
builds consensus, and sells/executes solutions across all domains and
operating groups as well as EA management.

- Recommends appropriate enterprise processes and action plans to operating
groups architects, developers and technicians, as well as EA management on
technical and infrastructure issues after completing a situation or context
analysis.

- Oversees and has technical ownership for assigned projects as being the
expert on all aspects of the enterprise architectural domains as well as for
any R&D projects.

- Understands and communicates technology dependencies, enterprise services,
enterprise capabilities, and industry trends that align to the EA Practice
road map in order to gain consensus and buy-in from various operating groups
and other entities.

- Work with IT Operations Service Owners in order to ensure enterprise
architectural solutions can be operationalized and maintained to meet or
exceed SLAs as well as business capabilities and can integrate into
strategic initiatives.

Thanks Kalman. I've already analysed scores of job descriptions like this,
and that is typical of the waffle that HR put together in career paths and
recruitment ads for EA team members.

Basically
This "EA" is a solution architect working at a high level and across
multiple projects with a view to enforcing enterprise IS/IT strategies.
This role is at the strategy/governor end of the EA scale (opposite to the
librarian end). There is no mention of any architecture repository.
This role is firmly located in IS/IT (is not a business management
consultant of the MS motion kind).

Notice "Defines architectural solutions for using enterprise services,
application system solutions, technical infrastructure integration, and in
some instances, business systems architecture" and "relationships and
dependencies to, operating groups, IT Operations and the Enterprise
Architecture Practice."

Your grammar could be clearer, but in short, I gather your enterprise
architect is once or twice a year invited to attend a "board-like structure"
where the management team talk about "business infrastructure" including,
but not limited to organisation structure, teams, departments, application,
information, and IT infrastructure.

Not really shaping the business architecture then? Not playing the proactive
role that William's business management consultants do using MS Motion?

Is the UK really that different from the US or any other place in terms of
management? You have customers, products, processes, production structures,
and culture. You have MODAF, PRINCE2, ArchiMate, and the TOGAF, which can
all be supported by the extended EA process I've described.

You have work-functions, processes, and input/control/output/mechanism
resources, all packaged as "capabilities" to fit the requirements (for
quantities of resources of given qualities on a given schedule) of your
organization units and their assigned functional duties, within your
organizations and their missions, across your locations. These things are
ubiquitous whatever the country, language, etc.

Do EA really advise CEOs and business managers outside of IT? It is rea
lly confusing and not really in concurrence with the Enterprise Architect's
definition/concept. Why do we need this momenclature "The Enterprise Archi
tect" per-se, there had been the "Business Advisors","Domain Experts" etc e
tc.

Most sources on this concept including the propogators of EA sugg
est on the following lines about EA.

The primary goal of the Enterpris
e Architecture Initiative is to establish a process which is focused on bui
lding and maintaining an enterprise-wide technology/system architecture tha
t essentially facilitates the adaptation of technology to the current and e
volving business needs of the enterprise. Architecture encompasses data, ne
twork, application, and security on IT/IS front and is based on the busines
s strategy decisions, financial analysis, and business process analysis and
design. The Enterprise Architect normally creates a high level design whic
h can be used by an enterprise to manage information more effectively. This
design is used by network engineers, application designers, database desig
ners and so forth to drive detailed functional designs in each of business
specific areas

Why do some Very Experienced and Intelligent Profession
als try to confuse the concept of EA per-se by assigning him role of a busi
ness advisor?!

I really do not think it is that confusing, business advisors 'advise' on
operational aspects of an organisation (e.g. how a current/new product such
as a derivative for an inv. bank, will perform and the direction that should
be taken for the product etc), following policy designed by an EA.

The EA builds/designs Governance process for corporate and IS/IT 'strategy'
(after it has been approved by managers) it is implemented and followed.
Whether you are a Solutions Architect or Business Advisor, there will be
certain aspects within the policies which guide your 'tactical' activities
as to what you do and how you do it.
They may not be as 'clear cut' or visible as stated here, but there would be
some type of governance (process) that all roles follow.

As you said "The EA builds/designs Governance proces
s for corporate and IS/IT 'strategy'----",thats understandable (although I
would like to replace "and" in this statement with "plus" or rephrase as IS
/IT strategy as per the business rules and processes) but "Do EA really adv
ise CEOs and business managers outside of IT?" Please note "outside of IT/I
S!!",If answer to that is yes then it comes in conflict with
the basic
definition of EA as proposed by it's proponents.

regards,
akshaya bh
atia

On Fri, 30 Mar 2007 CurtisJohnson via enterprise-architecture-
sp wrote :
>
>
>I really do not
think it is that confusing, business advisors 'advise' on
>operational a
spects of an organisation (e.g. how a current/new product such
>as a deri
vative for an inv. bank, will perform and the direction that should
>be t
aken for the product etc), following policy designed by an EA.
>
>The E
A builds/designs Governance process for corporate and IS/IT 'strategy'
>(
after it has been approved by managers) it is implemented and followed.
>
Whether you are a Solutions Architect or Business Advisor, there will be

>certain aspects within the policies which guide your 'tactical' activities

>as to what you do and how you do it.
>They may not be as 'clear cut'
or visible as stated here, but there would be
>some type of governance (p
rocess) that all roles follow.
>
>Different levels of abstraction.
>

I am going to say an aprehesive yes to the question... aprehensive because
it is not so black and white... advice can come in may shapes and sizes,
either directly or indirectly, and for a CxO to make decisions based upon no
information (or no advice) would not be good.
An EA has a responsibility to 'create' advice for the whole business'
'Architectural' environment. Whether it be just business areas, just IS/IT
areas or areas that pertain to both.
Hence the labels 'Enterprise' and 'Architect' in this discussion as oppose
to 'IS/IT' and 'Architect'.

I do not think this is a conflict, as I am a proponent of the EA proposal,
therefore part of the proposal should cater for this view.

Disagree:
There is a duty to advise what is possible, practical, or simply
achievable.
How this advice gets through depends on the org, I suppose.

Sometimes, also, it is simply the job of an EA (or anyone else) to
execute
the vision.
If, when Kennedy had said in the early sixties "we are going to put a
man on
the moon", and everyone had jumped in with cost-benefit and feasibilty
studies, it would never have happened.
[quick take-out]
1) Some say it never happened, and was all filmed in hollywood anyway
2) During later years, exactly what I describe above occurred, and the
US
hardly has a space programme anymore.
</end take-out>

Once again though, we are focusing on the ISS/IT side of EA - I repeat -
this
is not the beginning, middle, and end of your architecture - it has
*PEOPLE*
in it, for goodness sake...

If some Enterprise Architects operate from the assumption that their
interests are bounded by the IT of the organizations enterprise, then
the
"primary goal" cited below might make sense. However, other enterprise
architects see the boundary of their interests at the boundary of the
enterprise, encompassing all the named things within it, the
relationships
between them, and the attributes that characterize them, at the current
time, in the possible futures, and in the past. The also have interest
in
those things that touch the boundary of the organization's enterprise,
from
both a value-chain and security perspective.

So this group, like other EA groups before it, needs to recognize that
there
is Enterprise IT Architecture and Enterprise Architecture. Both use the
same core metaschema, populated with the same core data, but having very
different purposes, outputs and outcomes.

This is exactly analogous to the situation in the "Organization
Effectiveness" (OE) camp a decade or so ago. Some OE workers operated
from
the assumption that OE was about sociology, psychology, motivation, etc.
Others operated from the assumption that it was about "engineering"
organizations in terms of staffing, structured, skillsets, workflow,
etc.,
to make it more effective. Meetings that involved the "soft OE" crowd
and
the "hard OE" crowd were always interesting and seldom got anywhere. It
was
only when they established boundaries where no "exclusions" occurred
that
they began a quiet resolution of their differences.

It's also analogous to all those who "operate" claiming the word
"Operations" as defining their domain, when a liberal use of adjectives
is
needed to identify their actual domain. For example, a logistics
operations
is not the same as a medical operation, military operation, machine
operation, mathematical operation, software operation, etc., other than
that
purposeful work is accomplished.

In the case of Enterprise Architectre, the "Big EA" of the whole
enterprise
includes the "Little EA" of IT. IT EA excludes the majority of the
architecture of the organization's enterprise.

Think about an organization as a set of foothills, with valleys,
villages,
homes, with streets between homes and roads between villages and
valleys.
IT EA is operating from a "village view" of the organization, while Big
EA
is operating from a mountain-top view of the organization, both using
the
same mechanisms, but to address different needs based on different
vantage
points. I would submit holistic EA (HEA) and IT EA as appropriate
nomenclature for these vantage points.

The same technologies and techniques that model and store IT EA content,
perhaps with gigabytes of metadata and data, can fairly easily scale to
modeling and storing terabypes or more of metadata and data for HEA.

There is no disagreement on Enterprise Architecture as a discipline
being Business centric as well as People Centric.Also, as per CEOs and CIOs
seeking or getting advise from the EAs (who I am sure are competent to off
er such advices) is comprehensible. The query was directed to access the re
al role of an Enterprise Architect? Does any EA's Framework suggests that t
he EA's functionality includes the advisory on the business matters or is i
t design of the IT/IS architectural layout in alignment with business the a
ctual function of an EA?

Your email reminds me to clarify my point of view on EAs and consultants.

BUSINESS MANAGEMENT CONSULTANTS ARE NOT EAs
I have consultant friends who call themselves EAs and work on EA assignments
My friends are business management consultant who use EA techniques.
Just like William H's friends who use MS Motion.
They might call themselves EA consultants. But they are not EAs.
A proper/true EA is a direct and senior employee of the enterprise itself.

VERY FEW EAs ARE BUSINESS MANAGEMENT CONSULTANTS
Everybody in this group is in 100% agreement that EAs must understand the
business and align IS/IT solutions with the business.
The recent debate is only about how far the EA job is a business management
consultant's job.
In my view, people like Nic are very unusual in spanning both.

Organizations are "living" things because they include people. An
enterprise is the process by which the living organization achieves its
goals in accomplishing its mission. An architecture can be described the
"structure" of that organization's enterprise to the degree we can capture
it as it continually flows and adapts to internal changes and its changing
environment.

As I've stated in other fora, "nature has structures, and man models,
represents, and works with that infinitely complex natural structure with
what is called "architecture". This also goes to the idea, blending a few
metaphors here, that an architecture of an organization's enterprise, as a
detailed map of a process, is not the territory of the living organization -
the map is not the territory.

Hi David, we don't have it in hand yet. The EA initiative is underway
and there are many mountains to climb. A regular quip among the EA team
is that business keeps bringing mountains to Mohamed. I am fortunate to
have a strong team. A white paper will be forthcoming (probably by
Aug/Sep) and it will definitely be shared with the group.

1) Our approach is built on certain fundamentals, one of which is to
view the Zachmann or any other framework for that matter, as being
something like a Rubick's cube. I say "something like" because each cell
in every row is viewed as a pyramid laying horizontally where
intensification of granularity happens along the z axis rather than the
y. The topmost (and facing) view is the top of the pyramids cut-off and
expanding in extent and magnitude (along z) towards the base. The
relationships and associations both vertically and horizontally need to
be abstracted and balanced at every level as one moves towards the base.
So every level is an "enterprise view" but at different levels of
granularity. Determination of the extent and magnitude of the
relationships and associations for every cell at every level requires
appreciation of the x,y & z dimensions.

2) What has also helped is the approach toward primitives and
composites. The Periodic Table of Elements is a good example of a
framework which contains a "finite" set of primitive elements which can
be used in combination to create an "infinite" set of composite
elements. The framework and criteria applicable to primitives however,
cannot apply to composites even though they are made up of primitive
elements. If a business need is for a cup of orange juice then one would
use the primitives to create composites like the water, sugar, colourant
and flavouring; yet the juice cannot be managed by the criteria applied
to any or all of its constituent elements nor their constituent
elements. A separate yet linked framework and criteria is required to
manage composites which includes their identity, life-cycle and value to
the business of the Enterprise. This is vital in linking the boardroom
with the engineering room. Picture a builder showing you stones, sand,
cement and water and saying "there's your balcony" and when you enquire
about the staircase the same primitives are shown to you again.

Hi Nic, I agree with you wholeheartedly, "ought" is the correct one and
I support what you say with regard to the lack of presence of a
technology savy person at CxO level. I think that the distinction
between the integration of business with technology as opposed to the
support of business by technology needs to be made.

A business management consultant does not necessarily, but can, build and
maintain an architecture (with identified as-is and to-be states,
strategic/operational/tactical transtion plans to address the as-is
strengths, weaknesses, opportunities, and threats (SWOT) and the value-chain
satisfaction and requirement, and configuration change management such as
architecture and IT governance boards/processes of the client organization's
enterprise).

In my view, those persons and groups who call themselves enterprise
architects but only address the organization's enterprise from an IT
investment and development perspective are not giving the client the full
value of their skills, and of the metadata and data they have collected in
the course of their activities. These IT EA are routinely expected and
called-upon to do more for the organization. These IT EA can do more for
their organization/client if they broaden their view by taking a higher
vantage point.

I like the way that Mohamed describes the metaschema he uses. Our
approaches are probably interoperable.

My approach uses seven hierarchical subject root classes (i.e., taxonomies),
as primitives. These classes have subclasses and instances down the
hierarchy. I have seven relation_types used to define generalized relations
between classes (i.e., primitives), which are also used to categorize the
specific verb-phrases describing the specific relations between instances.
I have seven "value-chain" roles which are assigned to the participating
instances in a "flow", "sequence", "dependency", "production", "process",
etc. relation.

In each case, a "triple" of instance-relation-instance has direct, and
indirect or inferred, relationships to the broader set of triples in the
architecture, giving each triple a surrounding "enterprise" context.
Everything has a broader organization and environmental context.

Why on heart would my status as consultant as opposed to employee would deny
me the status of EA? Who said I was a Business Consultant? What logic
drives that assertion?

I oppose your viewpoint as illogical and without foundation.

One's status does not determine their qualification, skills or capabilities.
Isn't your statement another form of discrimination?

If I did not have the capabilities, knowledge, skills and accreditations,
why would a clients (typically employees of a firm) repeatedly hire me and
my staff to perform that function for the enterprise? Are they also deemed
incompetents or otherwise?

I'm leaving this particular thread with a few thoughts on motivations and
the market place.

I have been for many months now been trying to make sense - in the UK
employment market - of what employers mean by Enterprise Architect. My
motivation has been to improve the consulting and training services I
already provide to develop Enterprise and Solution Architect capability. I
want to be sure I pitch my services right.

In the last few days I have reported something of what I've found and the
best-fit interpretations I can put on it. These are not views I consider
ideal in any sense - they are only what I have found and concluded in my
attempt to make sense of the market place.

We can all call ourselves anything we like. Some of my best friends are
consultants who call themselves not only Enterprise Architect but even CTO
or CIO etc. That's consultants for you. Obviously, there are many in this
group who consider themselves to be an Enterprise Architect. They free to do
this. The space that is Enterprise Architecture is not owned by any one of
us. There is however a market place out there that merits study and
understanding - and should be reflected in this group's discussions. And
that's why I tend to define the space they way I do.

Yes.
Clive Finkelstein with Information Engineering, James Martin with Enterprise Engineering, and John Zachman with Enterprise Architecture all came from the same organization, and had the same predecessor. They would all recognize all this activity around EA as stuff they've all seen before from their three vantage points over the same terrain - organizational operations (whether business, government, non-profit, etc.) and the technology supporting the operations (such as IT, facilities, furniture, automotive) and control its resources (persons, intelligence, funds, skills, materiel, services, space, energy, time).

You might be interested in exploring my EA "Framework" which seems similar to your "rubic's cube". See http://www.one-world-is.org/rer/owis/gem-core/GEM_Core-Collection.htm, starting at slide 520. Note that this is built on the "fundamentals", or "primitives" shown in this collection of diagrams.
By the way - the material at that site is now released into the public domain. I provide support for it, as requested, through the non-profit educational corporation I've founded to advocate, advance, and support the approach documented at that site.
Roy

Jean Jacques: In my terminology, a business consultant could be an employee, a contractor, a board member, a board advisor. If you perceive that the term "Business Consultant" is bounded only to being a contractor, then your perceptions of my previous article would indeed appear illogical.
Roy

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.