NOREX Select 020 Enterprise Architect Artifact

clutteredreverandΔιαχείριση Δεδομένων

31 Οκτ 2013 (πριν από 4 χρόνια και 7 μέρες)

122 εμφανίσεις

NOREX Select 0
20





E
nterprise
A
rchitect

Artifact


NOREX
Select

members
discuss Enterprise Architecture

Artifacts during this August
2011 WebForum, which is a follow
-
up to

the EA Workshop held at the Eaton
Corporation in June.
NOREX

retains the original, unedited version in order to facilitate
future networking.


Contact your NOREX Member Care Team for assistance.




*Please note that this is a transcript of an audio conference and it may contain misspellings and grammatical errors.


The names of participants have been abbreviated, and their organizations have been deleted from this transcript.



Introduction and presentation:
................................
................................
..............................

2

The value of artifacts

................................
................................
................................
...........

10

Organi
zational considerations

................................
................................
............................

11

Providing directional accuracy

................................
................................
...........................

12

Maintai ning patterns and bricks

................................
................................
.........................

15

Defining domai ns
................................
................................
................................
..................

16

Security considerations

................................
................................
................................
.......

16

























NOREX
Select

WebForum Transcript

Enterprise Architecture

Artifacts

August 10, 2011




Introduction and presentation
:





Moderator
:

Welcome to
today’s NOREX

Select WebForum on Enterprise A
rchitecture
A
rtifact
s
.
During the June EA Workshop in Cleveland

Eaton

IT managers

provided a
well
-
received presentation on their EA strategy, and today they will go into more detail
on EA artifacts.
Allen
M.
is the manager of
I
nforma
tion A
rchitecture at the Eaton
Corporation. Allen, you can go ahead and take over the desktop.


Allen M.
:

Today, we wanted to kind of do a follow
-
on the meetings we had at our facility
here in Cleveland a couple of weeks ago and really just do a deeper dive into our
artifacts, you know, what their definition is and how we use them. So, I am going to go
throug
h a presentation, and at the end, we will take questions from the crowd and
maybe have a good discussion about what we are doing versus what you are doing.


My agenda today really is to share examples of Eaton technology architecture artifacts
and how we
use them. The artifacts we are going to go over are our principal artifacts,
the reference architecture, our roadmaps, patterns, and bricks. Just diving right in here,
we like to look at our architecture landscape, if you will, and use an analogy of city
p
lanning. That seems to help people understand what we are doing with various
artifacts, what their purpose is and how they are used.


On the left
-
hand side here, I have kind of got a city planning map, and on the right
-
hand
side, we have got a Gartner mod
el of enterprise architecture. On the left
-
hand side, you
can see we have analogies for a city plan, a zoning plan, building codes, services and
utilities, approved building materials, blueprints for a building, and a building permit type
thing.


To us, t
he city plan is a high level view of where we want to go in the future. As you can
see, our strategies and our reference architectures dictate that. When we look at a
zoning plan, which is kind of a regional effect of your city plan, you know, what do you
want to do in different areas, you will see that we have technology roadmaps and
patterns. When it comes down to actually, you know, building in a region or doing
specific things, we have our building codes, which are our principles and our standards
and p
rocedures.


Some of the services and utilities
--
we stripe our enterprise architecture group into three
disciplines. We have a technology discipline, which is infrastructure, networks, servers,
and that kind of thing. Then, we have a solutions discipline,
which is focused on
applications and the business domain and how to provide solutions. Then, we have the
information architecture discipline, which is focused on kind of the infrastructure or the
area between applications and technology.


You might have i
ntegrat
ion, master data management, BI
, things like that. So, those are
our services and utilities, if you will. The approved building materials in our environment
are our bricks, which are technology components.


Then, we have blueprints for buildings and building
permits

and those are our services
that we offer and some of the reviews that we perform as projects are being conducted
within Eaton.


Jumping to the documents that I wanted to talk about today, of our
standard documents,
I am going to go through principles, reference architectures, roadmaps, patterns, and
bricks. The first one is our principles. Going back to the city planning, principles really
are building codes, defining where you can build and what
building materials may be
used for the construction of each type of building. Their purpose, you know, is to provide
documented, architectural information. It is going to aid project leaders, analysts,
developers, architects, anybody doing anything in IT w
ith what to do. It is one of our
guiding lights, if you will, on the activities we are going to perform. Within architecture,
principles affect us in several ways.


We have what we call an architecture impact assessment, where we review projects
and try t
o understand what their impact is on our environment. We have an architecture
review process, where we perform like a high level design review, and that is done by
our architecture review board. So, principles affect that when we are considering
projects a
nd whatnot. Then, we have architecture exception requests. This is where
someone wants to do something that they know is not part of our environment, and they
want an exception. Then, of course, principles affect our strategic planning. Principles,
for us,

are very high level things. I will go into that next. We have two levels of
principles. We have our guiding principles, which are fundamental statements about
how we do things in the IT group at Eaton.


So, they are statements about our customers, our pe
ople, what our investments are,
how we source thing, and what our governance is and accomplishes. They are very
high level, and they apply to everything in IT. Then below those, we have striped our
principles by domains. So, they are similar to the guiding

principles, except for they are
very specific to particular domains. We have application development principles, and we
have principles around, you know, the data center and how things are done there.


To kind of dive in, I thought I would show one of th
e principles that we have. It is for
enterprise data. This is one of our documents. We have kind of cleaned it up to make it
nice for sharing with folks. At the top of the document is a bunch of information to just
say what is in the document. We have, bas
ically, a principle, a statement behind the
principle, a rationale, and the implications. So, this principle is fairly simple. Data is
shared and accessible. There is a statement behind that, you know, what does this
mean. Data is shared among enterprise e
ntities and with suppliers and customers. The
rationale is probably pretty obvious in this case. We want to improve quality and
efficiency and make sure that things are consistent across the organization, those kind
s

of things.


After the rationale, we wi
ll go and have a section of implications, you know, what does
this mean when you are conducting your business at Eaton. You want to make
investments in technologies where sharing the data is enabled. You want to make sure
that when you are working with dat
a you are taking into consideration how it might be
shared across the organization, things like that. When you are working on projects, or
when you are considering options for what you are going to purchase or build, this is
one of the principles you have
to take into account. So that, in essence, is a principle
document. We have a lot of those, and they are used very commonly. I would say, my
experience, when they are used the most is whenever we have a design discussion or
we are reviewing something, and
we seem to start to miss on a topic or get off track. A
lot of times, we will refer back to the principles, and that helps bring a group back into
alignment. So, they are actually very handy to have.


OK, so, the next slide I wanted to talk to was our ref
erence architectur
e. A reference
architecture is

a very high level definition of what we view our IT environment to be like.
It is kind of like a city plan. It is a city plan in the sense that it shows how we want our
city to be in the future, across the e
ntire city. It may not be regional, but it is going to
say, for instance, in a strategic area, we want to work with these technologies, we want
to exclude these other technologies, and we want you to have these types of
functionalities.


So, to kind of re
cap that, they are very strategic. They are geared toward strategic
initiatives. We have reference architectures, for instance, for our product data, or we will
have a reference architecture for integration, or we are working on reference
architectures for

area around our portal or our employee data. Once these reference
architectures are developed, they have a strong effect on our strategic planning and
how we do architecture reviews. They also affect our roadmaps and patterns and bricks,
which are documen
ts I will discuss later. So, they are very wide
-
ranging, but they are
strategic and geared toward a particular business area. As far as what a reference
architecture document looks like, for us, they are kind of wide
-
ranging, but they do have
three major c
omponents.


The first one is, and you will see this on the left, a reference architecture has a desired
future state. So, we want to focus on where we want to go, what the landscape will look
like in the future. It will have a reference model, which is ki
nd of a logical description of
the components and their interaction. Then, it will also have a deployment architecture,
so taking that reference model and breaking it down into something that we could
actually start to install or build is the last step. It

is kind of a progression, if you will, from
a very high level view of what we want to accomplish down to the actual, you know,
where the rubber meets the road, what we are going to deploy. That is what a reference
architecture is.


One thing to note is that an architecture reference, for us, is a forward looking
document. So, there is a potential that components or parts of the reference model are
not deployed at Eaton right now. We will use this reference architecture to guide the
d
eployment or development of products in those areas.


So that is reference architecture, and the reference architecture has a direct effect on
roadmaps. When you consider that a reference architecture is the desired end state, our
roadmaps are documents t
hat indicate the activities or the schedule of activities and the
dependencies between those activities that are all necessary to get to that end result,
that reference architecture. For us, that is kind of our zoning plans, if you will. Probably
everyone
is familiar with a roadmap, or they have seen roadmaps developed. It is going
to show us all the activities and the interrelationships and the dependencies. Roadmaps
have a great effect on how we do our architecture reviews.


When we do a review, we are g
oing to make sure that what someone is doing is
following the roadmap. It also affects our architecture exception requests. If someone
wants to do something, and it does not follow a roadmap, we will not let them have that
exception. Then, because roadmaps

are a slightly lower level than a reference
architecture, they do not necessarily affect as many things, but they will affect our
patterns and our bricks, moving forward. Again, roadmaps kind of vary widely. We do
not have a standard format for roadmaps.
The one we prefer has two levels. There is a
business strategy on the top, and then below that will be an IT strategy.


Then, we will have, of course, a timeline, which is a part of every roadmap. In this one,
you can see that the business wants to accomp
lish certain things at the top. Below are
the dependent IT initiatives or projects that must be executed for them to realize their
business strategy. There is a strong tie
-
in between our business strategy and our IT
strategy when we do these roadmaps.


OK
, next up
are our patterns
. Patterns, again, are kind of like our building codes. What
they provide is a way to use the most pertinent materials in the best way. In an
architecture sense, what we are showing designers and developers are the proper
combinat
ions of components to use. The goal of the pattern is to use things that have
been done repeatedly, and through that repeated use, we have tested and verified their
viability, and so we understand the quality of what we are doing. Patterns really have a
st
rong
effect

on how we do architecture reviews. When we do a review of a project, we
look at, you know, what are the patterns being used, what are the patterns that are
being violated, and can make a decision, and it takes away the arbitrary aspect of a
des
ign review when we look at patterns. So, we can make a decision based on an
established pattern and kind of rate the project.


We have recently deployed an architecture impact assessment process that is baked
into our project portfolio tool, and patterns
are used there, as well. When someone is
actually running through and conducting a project at Eaton, there is a point in their
project where they actually have to go through and list out the patterns that they are
using, as well as the bricks. That is used

to assess the risk of the project. So, we use
patterns to assess risk, as well as to conduct design reviews of projects. Patterns have
a very powerful effect on our bricks. We will go through that later, but the patterns are
going to dictate what types of

bricks can be used and when they can be used. So, here
is a high level view of a pattern. Each pattern that we create has an abstract, a
description. It will have a use case. In some cases, the use case in when and when not
to use the pattern, or in some
cases, it is a decision tree that will indicate which part of
the pattern you should use. Then, it will have an architecture. The architecture really is a
diagram. You can see an example of a diagram below, in the bottom of this
presentati
on. This is actua
lly for a J2EE

application. It will have a component list, and
the component list is very specific for us. That is because a pattern is, to us, what you
can do right now. There is no forward looking aspect to a pattern in the way we deploy
them, so it is a

snapshot of what you can do right now. So, we are very prescriptive
about what types of components you can use. There are actual version numbers
involved in a pattern, for instance. After the component list, then there is a section
where we have guideline

for how you can actually use this pattern, or best practices, if
you will, what you should do and should not do when you are using this pattern.


Here is an example of a pattern. We thought this would be interesting to look through. It
is our enterprise
reference data pattern. We can go through, and you can obviously see
the sections of the pattern. This particular pattern refers to a way of accessing,
obviously, enterprise reference data, which is the data that may be centralized or in one
location but i
s needed by many other systems to perform their functions. So, we will
have a description here of what the pattern addresses. We will have a use case, which
in this case is just a technical description. It is basically saying, hey, if you want to get
emplo
yee data, reporting hierarchies, Eaton locations, or GL codes and accounts, you
should use this pattern. Then, it goes right into the architecture. Really, the architecture
and the diagram are the things that are of the most value with these patterns.


Ob
viously, you know, a picture is worth a thousand words. This kind of shows our
developers and our reviewers and our designers what should be done when you want to
get enterprise data. Here in this case, we have got a situation where we are housing
enterpri
se data in a schema inside a database. All the applications that are co
-
located in
that same database can use that schema. Or, we have situations where applications
are in a different database, and they should be accessing that schema through a
different m
echanism. Again, this kind of gives a guideline for how things should be done
and also the components.


After that, we have the component list, and we specify which items and their version
number are part of the pattern. So, here, you will see we have got

Oracle 11
g
R1 is the
enterprise edition of the database we are using. We have got another component which
is not really part of a brick, and it is the enterprise data schema. That is a custom
-
built
database schema that we have deployed to house all this in
formation. What the pattern
does not really show is that we actually replicate this data to various databases so that
applications have an opportunity to get this data and not have to build connections to all
many types of systems.


Then, we have some gui
delines. This is kind of some information about the underlying
systems, guidelines like, do not except this information to be real
-
time, do not make
copies of the entire database, just use what you need, link to the rest through IDs, you
know, use master d
ata management, hubs, for instance, rather than the enterprise data
schema if you need to get master data, etc. etc.


The last part of the pattern is that issues section. That is where we actually keep track
of any issues, procedural or what have you, ass
ociated, with the pattern. For instance, if
a brick is missing or it needs to be updated, we would list that issue here, so when
people are reviewing the published materials, they understand that there may be some
issues with the pattern. Then, we have gui
dance about what to do depending on what
the issues may be. We may, for instance, say, you know, a brick is missing or out of
date, but you still have to take that into account, it does not give you a pass, something
like that. So, that is a pattern docume
nt.


The next level and the lowest level of the documents that we deal with here at Eaton are
our bricks. If the patterns are a definition of what bricks can be used
--
you know, the
bricks are the very lowest level. I guess the relationship is, we could
have patterns, or
rather, we have bricks for databases and we have bricks for servers. This is a good
example, actually. We have bricks for databases and bricks for servers. Theoretically,
you could grab any server and any database and say
;

hey, these bric
ks are valid, why
can’t I use this? The reality is that there are only certain types of databases we run on
certain types of servers. That is indicated in a pattern. The actual bricks and what are
the valid components are in the brick document.


So, brick
s are very important for us when we are conducting our architecture review.
We obviously want to make sure that people are using the appropriate components. It is
also important when people are asking for an architecture exception request, especially
in ou
r procurement process. When people want to install software or buy a component,
our procurement team will not do that unless the component they are requesting is on a
brick. If it is not on a brick, they immediately generate an architecture exception reque
st,
and we go through the process of validating what component they want to use or
guiding them toward the proper component.


So, here is what a brick is. You have probably seen this before. This is fairly common in
the architecture world. A brick is kind

of both. It is kind of a layered document, if you will.
There are three layers to it. The top layer, you will see, moving from left to right, shows
a baseline environment, which is what we have currently installed in our environment,
and then it has a tac
tical box, which tells you what things you can buy right now. Then, it
has a strategic direction, which is what is coming up next, you know, in a couple of
years, what should you be looking at, and how should you be thinking and aligning what
you are buyin
g now towards what we strategy is.


The middle level of a brick is the life cycle of a component in our environment. It is
intended to line up with the layer above it, so if you go down and look down from
current, you would see the baseline and then you would also see the lifecycle area that

is called retirement targets or containment targets.


Then, you would have, in the tactical layer, if you went straight down from that, you
would see in the green box, the things that are preferred. In the gray box below it, the
containment targets, you
would see items that are, you know, not necessarily preferred,
but OK. In the strategic direction below that, you would see emerging technologies and
the next generation. So, you can follow the arrows here. A component actually makes
its way onto the brick

on the right
-
hand side as either an emerging technology or a next
generation item, and then it moves into the tactical deployment. Then, as its lifecycle
progresses and it ages, it may move into containment or even retirement.


At Eaton, when we actually

put something in retirement, it is required that there is a
project underway to retire the item. So, it is not just kind of a wish list. It is actually being
done. The idea is that the brick does maintain a fairly accurate representation of what is
in our

environment and what is leaving.


The bottom layer of our brick document is our implications and dependencies area. That
is really a place where we can textually describe situations or things about the brick.
You will see;

we actually have an application

that renders our bricks.
It is important for
us to have a place to put text to offer guidelines or rules or restrictions on some of the
components. So, we have a group of domains that our bricks are ordered by. You can
see there, there is the list. We hav
e application development bricks, applications bricks,
content, collaboration, data, desktop, and workforce productivity, engineering is a new
area we ventured into, integration and interoperability, network, platforms and storage,
security and identity, a
nd systems management.


I am going to show actually one brick that we have. This is our enterprise database
brick. Again, you can see at the top, we have got our current environment, which is
obviously very large, because we have got a lot of databases at

Eaton, our tactical
deployment, which says these are the things that you can deploy now, if you want to
build a database, and the finally, the strategic period, so where we are going in the
future. You can see this is a good example. We are actually whitt
ling our product list
down. When you get down to the lifecycle part of the brick, which are the colored
blocks, you can see that our preferred choices right now are Microsoft SQL Server 2008
and Oracle 11
g
R2. The next generation, we are looking at Software

AG Adabas, IBM
DB2

V
9, and Microsoft SQL Server 2008. I do not believe we have a next generation for
Oracle right now. It does not mean we are retiring it. We are just not sure where we are
going to go with that next.


We do not have any emerging technol
ogies that we are considering in the enterprise
database area. We have suboptimal choices here, which are the Software AG, IBM
DB2, Oracle 11
g
R1

i
n
p
rogress, as well. On the far left
-
hand side, you can see that
there are things in our environment that we w
ish to retire. So, right now we have
projects underway to retire those database items under retirement targets.


Then, we also have an area where, things that are in our environment, you may be able
to do, but you would have to get an exception to do it.
We want to control what is being
done with those items. So, you will see, like, Microsoft SQL Server 2005. If you wanted
to deploy that, you would have to have a very strong business case. Let’s say you just
had to buy a product that only ran on SQL Server

2005, or something like that, we
would consider letting you do that, but you would have to talk to us and justify it. At the
very bottom, we have some implications and dependencies associated with this brick.
Progress databases are only to be used with MF
G
/
Pro. It means we are not doing any
g
reenfield development with Progress. If you want to talk to someone, obviously talk to
the data domain team. We have architecture domain teams.
Then, some statements
about older databases
; d
epending on migrations and w
hatnot, you may be allowed to
keep an older database.


So, that is a brick document. We have, I am not sure exactly of the count, I think it is
over 200 bricks at this time, that we maintain and try to keep current. To help us with
that, we have, at Eaton
, what we call our brick application. It is embedded into our
enterprise architecture site. It is a tool that we use, and also anyone working on a
project or wishing to buy something also would be using it.


I will just go through
here;

we can search for
bricks or browse bricks. It is a custom
-
built
application that we have. I can show you, for instance, if I wanted to look at database
management systems, I could go and in real
-
time pull up the current brick and see that
online. Then, if I wanted, of cours
e, I could generate a PDF for this. So, this allows us to
move through and manage our bricks. I see a chat message, there is a question there. I
will address the question. That is a good question. I will get that when I am through with
the presentation her
e. So, this is the tool we have. It is actually very helpful. It seems
pretty simple. It is maybe not so simple, but underneath it, we also have a publishing
process and a way of entering in products and vendors.


So, there is a little more to it than jus
t what is on the surface. That is very helpful for us.
That is really what I had to show and talk about. For our documents and artifacts, it was
actually kind of cumbersome, because I kept getting to the point where I wanted to ask
for comments, so maybe w
e can open up the floor and take some questions.


Moderator
:
Let’s take the question that came via chat.
Are you bricks that are
documented more infrastructure pieces of technology or business applications or both?


Allen M.:
It is definitely both. I mean,

we have a section, and probably half of our bricks
are buried under one domain, and that is the application domain. That domain consists
of applications for all our major business functions, HR, finance, you name it. It goes
into operational excellence. W
e did break out a separate domain for engineering,
because it was just turning out to be too cumbersome to keep that underneath the
application space.


Topic: The value of artifacts


Moderator
:
We had a question submitted beforehand from Pukhraj, actually
a couple.
He is wondering if you can provide some evidence of business value through the
artifacts.


Allen M.:
I am not sure we have a lot of metrics on the business value. I mean, we have
a lot of ancillary evidence, I guess. We do not have any hard metrics, but for instance, in
our procurement process, the usage of the bricks has helped us greatly in constraining

the variation in our environment. So now, we have visibility about what people are trying
to install.


Right now, our support people will not install a piece of software if it is not on a brick and
an exception request has to be made. We are able to cont
rol that part of our
environment. Our patterns are relatively new. Earlier this year, we deployed our
patterns. We have seen evidence.


Again, we do not have any hard metrics, but they are definitely helping and guide
conversations, you know, when people
are executing a project and get to a certain area.

Let’s say they want to move data from one system to another. We can pull out the
patterns and guide the conversations. It is definitely helping keep people on track.


Jim C.
:

I can take a stab at that Alle
n. I am part of the architectural group as well. I don’t
think that we have strong evidence but the two pieces of evidence that I think we are
finding are one that it is really helping with us to stress the need for
license

compliance
and it really reitera
tes the fact that if something isn’t a standard even though we might
not prove an exception they can only be installed by the local sys people with proper
licensing.


So a lot of times you have licenses that you can deploy. People don’t understand a
licen
sing compliance behind that, the architecture process in the bricks helps to
reiterate that to the end user who may not care or they just think it is assumed.

The
other piece of evidence I think, we are a very large company and very slow moving
because we
have so many applications to test and for the first time in a while we have
been able to count the number of applications on the desktop and get the local support
people to stop installing software without an exception request and the driver has been
to ge
t us to a newer platform, you know Windows 7, a newer version of Office and a
newer version of Internet Explorer.


We have been able to draw that line to say that these are the documented standards
that matter and one of the drivers for not approving additional pieces of software where
these is a business value is because we don’t want to have to go through the testing

process for additional products. We have about 892 applications that matter. We have a
total inventory of over 7200 unique applications. So this has helped us be able to plan
and start migrating to Windows 7 and future products instead of being stuck beca
use
applications are not compatible. Besides that we don’t have a lot of evidence yet that we
need to do a better job of measuring benefits.


Moderator
:
Do you feel that you have got a
fairly

mature EA process compared to
other

companies? Do you feel tha
t you are maybe down the road a little further than
most?


Allen M.:
That is a good question. I think so. We have been doing this now for at least
six years. I would like to think that we are somewhat mature. We do have strong areas
in our tie in with pro
curement and our bricks and knowledge around that is pretty strong.

There are some areas where we are just picking up speed but that is probably normal.


Moderator
:
Let me ask the other folks on the call today. It looks like there are 11 or 12
other organ
izations. Does anybody else have an EA program this advanced? Where do
you folks stand with your EA program compared to what we have heard today?


Ge
orgi V.
:

I can speak to it. We have somewhat of an enterprise architecture initiative, I
want to say, but
nothing is really made operational across teams. Nothing is at the
enterprise level. We have kind of siloed architecture teams, if that makes any sense. So
they kind of operate on their either particular business unit or particular organizational
unit if y
ou will. So I think we are at a point where we see the need to make a large
investment in that area. Hence our participation here.


Topic: Organizational considerations


Allen M.:
Actually Georgi, I did see your question on the architecture group and
oper
ational unit. What do you mean by that? What do you mean by an operational unit?


Georgi V.:
Do you have like a department that does that? Do you have a group of
people that their sole responsibility is to come up with the architecture, patterns and
design
s and enforce them? To what extent, how big of a role do they really have? Does
this group have any teeth? Can they drive requirements even from people that feel that
position is not the most important in the company and things like that? I guess it gets
p
olitical on some level but I am just curious to know how you guys solved that.


Allen M.:
Sure, yes. We are operational. You have to understand Eaton a little bit. We
are federated. We have three main entities. We have an industrial sector, an electrical
sector and a corporate sector. The enterprise architecture group is part of corporate and
we deal with architecture issues across all three sectors. We are in charge of all of the
artifacts

that you saw. We do work
through

domain teams.


Our team, I think we have ten members right now. We have ten full time members but
we work a lot with domain teams to help us with some of the architecture items,
especially the bricks. I don’t think there is any way we could deal with all of the bricks
as
sociated with the enterprise. We are operational.


We do have, I will call it teeth, but of course architecture is one aspect of
anything

that
you are dealing with. Something could be architecturally unsound but the business
driver behind it could be huge
. We rule on architecture but there are times when we do
get overruled because of the business case and that is part of life. We are able to make
changes in projects or things that are going on.


Topic: Providing directional accuracy


Moderator
:
I just se
nt a chat that came in from Bret
t

to everyone. Brett,
I am going to
need you to elaborate on this.
For areas such as integration options do you address via
p
atterns and how do you organize? Then you have got an example there that looks
pretty detailed.


B
rett A.
:

It only looks detailed because I typed a lot. I guess one of the things that we
are looking at is driving value across the organization. Part of that is providing
directional accuracy in terms of approach. So I was wondering what is the vehicle that
you u
se to do that. An example that I have is that typically we will get into issues where
we will have sort of point
-
to
-
point, system A to system B. It is very provincial so A needs
to talk to B and B needs to talk to A. There really isn’t a lot of need for ab
straction or the
ability to translate things ______ canonical (?) model.


Other cases we will see options where we might actua
l
ly need to involve multiple
systems and there is
orchestration

and at that point it seems like you need to provide
direction. So

I am just curious, is this how you would manifest it in terms of a pattern or
would you have something else?


Allen M.:
That is a good question. Really that would fall into two areas I think. When
you
look

at the point A to point B. scenario that is reall
y going to be a pattern. What type
of data movement do you want to perform? We actually have an area, our patterns are
kind of grouped by areas and then we have application patterns, base patterns and one
of the areas is data movement. Eaton buys a lot of
stuff and then we have to hook it all
up, right? So that would be a pattern. It is a very specific example of getting data from
point A to point B and there are different requirements. Depending on the requirements
you would choose a different pattern.


Br
ett A.:
Are those patterns sort of a line towards the target destination system. So if I
am using an Oracle eBusiness suite I might say the pattern is; use open interfaces. If I
am using Seybold I might say the pattern is; use web services and have it at t
hat level?


Allen M.:
We distinguish which pattern you would use based on the nature of the
transfer and not necessarily on the technologies involved. Then within the patterns
themselves the use case part actually has a decision tree so let’s say if you ar
e doing
something like messaging or your requirements indicate that you want to do messaging
then underneath the messaging pattern you would see a decision tree. OK, I want to do
messaging from Oracle to Progress or something like that. Then part of that p
attern
would tell you OK, here is the technology you should do if you want to do messaging
from Oracle to progress.


Brett A.:
Do you actually carry patterns at lower levels too or do you keep them at a
high level? So for instance if you are looking at mes
saging, you were talking about that.
If I look and say there are a tone of patterns out there like claim check patterns and
enway (?) and so forth or is that something that you look and say we defer that to sort of
a domain group. Do you get the overall na
ture of the pattern you are
using?

You want to
get the coding or decorating patters and things like that, then that becomes the level
that is below the enterprise that you have some other vehicle to look at that?


Allen M.:
Yes there is some level where it

is kind of how much do we want to bit off
quite frankly.


Brett A.:
How much is this where you expect the people that are going to be executing
on a data base level to understand [inaudible] they really should understand the low
level
components

on that.

Then you could handle it some other way, focus areas or
whatever.


Allen M.:
Right, wehave right now our patterns at a
fairly

high level. Like the level I
described, you should do messaging. We don’t get down to the point where hey we tell
someone you sho
uld do publish/ subscribe or guaranteed delivery or what not. That is
really a conversation with the team that owns the messaging area and the solution
providers.


Pukhraj K.
:

We do have a similar scenario where you have integration from legacy to
the ER
P or from an

_____ or whatever or to the Sei
bold or PeopleSoft. So there are a
couple of things I think when you are talking about point
-
to
-
point integration based on
the mechanisms that you want to integrate like whether it is an event based or a batch
p
rocess or whether you are integrating from one database to another database or it is
going through some application business logic.


Based on that we defined various patterns.

If it is event driven and the payload is
lightweight so you use SOR (?) kind of a mechanism there. If you are moving like some
hundreds of thousands of records from one database to another database then you are
integrating the systems you use some other p
attern like maybe use some kind of an
ETL or something like that. So we do define those kinds of patterns at the low at our
organization. I hope this helps a little bit.


Brett A.:
I think that is similar to what we are doing right now. That is kind of
where you
always want to balance detail with benefit right?


Pukhraj K.:
That is right.


Allen M:

Right, that is not too far off from actually what we are doing. We have probably
five data movement patterns. We slice them a little differently. We look at
the amount of
latency you can stand to tolerate. So we look at real time verses batch and things like
that and not necessarily event driven

verses non
-
event driven. Then for real time maybe
high volume or low volume but still real time. So we have options
based on that but it is
all under one pattern.


Topic: Strategic planning


Pukhraj K.:
W
e do have a
fairly

organized

EA program. We are
primarily

focusing on
business areas and not as much on technical. More focus i
s

on how do we interconnect
the various b
usiness areas

with more emphasis on connection constructs. What should
be there in the connection constructs between diverse areas. Each area maybe can
operate autonomously as possible but the central features, the ones that we are
standardizing like archi
tecture assessments, we have not gone through detailed
technology lists. That is where we can get some benefits from what Eaton has shared
today. So one question is; are these slides going to be published that we can use them
in future?


Another question
would be what is your level of engagement with strategy planning
groups in your company, especially who deal with business architecture, the EA
program?


Allen M.:
I will let Jim talk about the strategy part I will say that we will make the slides
availab
le. That is not a problem.


Jim C.:
I think I understood the question. We have an IT strategic planning team and
we work with our customer relationship managers or our business relationship
managers in IT who are kind of liaisons to the different functions
. We collect their
business requirements as well as the Eaton business requirements overall when we do
the IT strategic planning.
So the strategic plan is kind of a high level. We don’t need to
understand what the function objectives in presenting any arch
itectural barriers to that
and how we would address them. So there is some tie to architecture but it is somewhat
of a loose tie because the strategy is such a high level. I hope that kind of answers your
question.


Pukhraj K.:
Is there any systematic app
roach in that aspect as to for instance
developing patterns which are

not so much as technology related and those in turn
could be
when

you drill down deep you can link to specific technology patterns.


Jim C.:
Yes, I think if there was a high level
strategic plan for example in HR to get to a
new system worldwide by some certain dates then in IT we would have to figure out
how we would do that and if there is an architectural requirement there we would
address that at the strategic planning level and

then it would kick off a project in IT to
help them accomplish that goal and see how that architecture might fit into the
environment. That is the example that we have is that in HR there was a big initiative.
Architecture got involved in the vendor selec
tion process because we knew it was a
strategic objective for the business for HR and therefore we got involved in the process.


Pukhraj K.:
What we are planning on trying to pursue is if you have any business
architecture uses for a particular area can th
at be shared or replicated or somehow
leveraged in different areas without even going into too much in technology detail. Then
later on have a group to manage technology separately.


Jim C.:
I think that our job as we have defined patterns reference archi
tectures is we
really try if there is a compelling business reason to shift gears and
re
-
architect
. There
really has to be a strong business case because we take into consideration the
switching costs of those things. So in the HR example that was
really

a

key
component

on how we selected certain vendors was what is our existing architecture and our
architecture roadmap and do these vendor fit that. If they do not what is the business
case and the switching costs and is it worth that switch or not.


Topic:

Maintaining patterns and bricks


Pukhraj K.:
Another question I think I may have is switching gears back to your main
topic of technology patterns and bricks, how difficult do you find maintaining those
dynamically because I am sure they must be changing quite a bit. Do you have a data
model which ca
ptures those
details

that could be dynamically changed as the data or do
you maintain them as SharePoint sites or Word documents that you have to constantly
monitor and be alert of that?


Allen M.:
That is a good question. We actually had that application
built because of the
challenges of maintaining the bricks. We started off maintaining those
PowerPoint

and
that was just, well burdensome is the nice way to put it.
Now that we have that
application it is much easier. We have enabled the main team members
to go in and
they alter
bricks

and then they go through a review cycle with our core team which is
really the enterprise architecture team.
That

is the core team if you will. Until we had
that application it was very burdensome.


Then what we have done to
o
without

patterns is we are using the Sparks Enterprise
Architect and we take a snapshot of our brick database and run that against our
patterns and it generates a report, you saw that issues section on a pattern. It will
actually indicate which bricks ha
ve become outdated on a pattern. So we know on the
patterns when we need to fix things if a brick is changed and it wasn’t the result of a
pattern guidance. Without that kind of automation it would be very hard.


Pukhraj K.:
May I ask what tool are you us
ing for that application?


Allen M.:
We have hooked up Sparks EA. So we are using Sparks Enterprise Architect
to access snapshots of our bricks database. The bricks database is just a custom tool
that we built.


Topic: Defining domains


Mark:

I was just
wondering about your domains and how those were defined. Was that
just, are they basically

referencing your organization or did you have some kind of
external model that you are following?


Allen M.:
That is a question that maybe Jim can help with. He has
got more tenure in
the organization that I do and I wasn’t there when that decision was made.


Jim C.:
I think the model was based on the old Gartner model. We looked at how they
had architecture structured and then we took their model and we saw how it fi
t with how
our organization is set up. We made some slight modifications but I think the high level
number of domains came from the original Gartner model. We added afew and then as
Allen said the applications domain was too large for functional applicatio
ns so we broke
out engineering as its own and we are continuing to do things like that kind of a work in
progress as we optimize the subject matter experts that make up those domain names.


Topic: Security considerations


Moderator
:
We had a question come in from Andy at PPG. It probably goes a little
beyond EA but I am sure it is something that all of your organizations are dealing with
and it has to do with the proliferation of iPads. Andy is asking how your organization is
dealing
with security and access. Andy, feel free to jump in.


Andy G.
:

I don’t know what everyone else is dealing with but that seems to be the drug
of choice in the last year at least. People want to use it from soup to nuts and there are
people that think of i
t as a replacement for PCs. Other departments think that they can
reduce costs and improve productivity. Our team has kind of made a little grid on the
utilization of it. It is an additive device for a significant number of people and only a
replacement fo
r a select few others. Relative to security and access right now we still
treat it as a foreign object so to speak.


Allen M.:
That is kind of how we are treating it. Right now iPhones and iPads in our
environment, we treat them as a personal device. If y
ou wanted the company to buy
one for you right now there would have to be a strong business driver behind it. No one
has really supplied that yet except for in the cases where someone is maybe developing
an app that they want to deploy. So people right now

can purchase their own iPad or
iPhone. Eaton will provision it but they are not connected to our network so security
wise they are using it as a phone.


Eric W.:

(Eaton)

Let me jump in on that one now. For the rest of the list
e
ners I am one
of the EA col
leagues on the call from Eaton. I have been involved in the iPad discussion
so I am going to see if I can chime in a little bit.
First off we just recently enabled iPhone
purchases by our employees.


So an employee can purchase their own iPhone through Eaton with their own money
but then Eton will pick up both the voice and the data plans for it and then it can be used
for email and that type of thing. We are right now just about fully deployed on a mo
bile
device management platform which we are using to help manage these devices. Very
shortly we are going to have the ability for people to purchase 3g iPads, through the
company as well with
their

own money.


On the iPads they are going to end up paying

for their own data plans as well because
that is typically going to be additive over and above what they normally have for a
phone.
In terms of connecting these devices to Wi
-
Fi currently they are prohibited to
connect
to

the Wi
-
Fi network. We have got to

do a little upgrade to our Wi
-
Fi
infrastructure before we are going to permit those to be connecting. That is kind of the
nutshell if where we are on the iOS type of devices right now.


Moderator
:

Eric, what tool did you select? Was it Iron Mobile or one
of the others?


Eric W.:

We are actually using Tango’s MDM solution.


Moderator
:

By the way everyone, our next workshop is going to be on mobile
technology. I have got a slide coming up on that later but it is on September 20 & 21 in
Chicago cohosted by B
runswick so we expect that to be a popular workshop in
September. Other questions or comments? By the way Allen, I think you said earlier you
would make the slides available?


Allen M.:
Yes, that is correct, in answer to Brad’s question.


Moderator
:
Thank

you. Anything else for the folks at Eaton? Great presentation, we
appreciate it.


Group:
Yes, thank you so much. It was good. Very good. Really appreciate the work.




End of discussion














Copyright 2011
, by NOREX, Inc.


5505 Cottonwood Lane


Prior Lake, MN 55372 The opinions expressed in
this NORVIEW are those of NOREX members, not necessarily those of NOREX, Inc.