Enterprise
Architecture: a journey, not
a destination.
GCN Interview
with Jan Popkin, founder of
Popkin Software and a strategist
at Telelogic.
GCN: What developments
are we likely to see with
enterprise architecture this
year? Some experts talk about
the need for more data management,
business processes and security.
Popkin: Enterprise architecture
continues to mature. There
is an understanding of what
it is, and people are saying,
“Now that we are doing
enterprise architecture, what
benefits or actions do we
want to result from that?”
It’s less, “Should
we or shouldn’t we do
the program?” [and more]
“We’re doing the
program now; let’s tune
it to our particular needs.”
Enterprise architecture is
a mechanism to provide results
— whether it’s
agility, alignment, collaboration
— and so…it is
an enabler in itself. I see
[users] looking for results,
tuning programs. The other
part of the enterprise architecture
discussion is moving further
out from an IT chief architect
discussion to involving extended-team
collaboration with other groups.
And that opens up the questions
of data management, business
process and security.
For instance, “We have
data we want to share —
what are the rules for sharing
it?” “We provide
this process or business service
— how can we share it?”
And security is an ongoing
discussion. In the past, there
has been discussion of laying
in a security view. I think
that’s always been balanced
with having security intrinsic
across everything you’re
doing and having it especially
called out.
GCN: We’re hearing
a lot about service-oriented
architecture and business
process management. How can
agencies apply these disciplines
and associated technologies
in an EA framework?
Popkin: When we talk about
an EA framework, I’d
like to map that into an EA
program. An EA program is
an ongoing mechanism to understand
what your goals are and what
an agency’s service
goals are and align that with
IT services and business processes.
So the enterprise architecture
program or framework provides
a context to understand the
implementation of such a thing
as SOA or business process
management.
But when we talk about SOA,
there are multiple definitions
of it. When I talk about SOA
in this context, I’m
talking about it as an architectural
principle, which means supporting
the agility of moving things
around over time and [supporting]
data sharing. I think in the
federal space that is what
people are talking about,
which is having that agility
and data sharing.
It’s not discussing
SOA technology, it’s
talking about the architecture
around it. Having said that,
you can see the alignment
of an EA program — which
involves understanding and
defining services, an agency’s
goals and what it needs to
achieve — and then having
the SOA architectural principle
below supporting that in a
high-level implementation.
As you do the services, you
have to involve the business
processes around it. When
you’re talking about
the SOA architectural principle,
there are people and things
around that and the processes
which are very important to
enable those SOA architectures.
Tying that all together,
the EA program is a higher-level
view of what’s going
on, how that’s aligned
to where you are and where
you are going.
