Enterprise Architecture News

Now Available for Ordering

Titled:

'Enterprise Architecture Good Practices Guide'

How to Manage the Enterprise Architecture Practice

Trafford Publishing, Canada

ISBN: 1-4251-5687-8

by Jaap Schekkerman

A 386 pages; quality trade paperback (softcover); catalogue #07-2553; ISBN 1-4251-5687-8; Price: US$73.12, C$73.12, EUR49.95, £37.75

This Enterprise Architecture Good Practices Guide is based on IFEAD's well known sets of EA guides that are published over the years and enhanced on feedback from users.

About the Book: Enterprise Architecture Good Practices Guide

The purpose of this guide is to provide guidance to organization's in initiating, developing, using, and maintaining their enterprise architecture (EA) practice. This guide offers a set of Enterprise Architecture Good Practices that have proven their benefits to organizations and that addresses an end-to-end process to initiate, implement, and sustain an EA program, and describes the necessary roles and associated responsibilities for a successful EA program.

Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.

While EA frameworks and models provide valuable guidance on the content of enterprise architectures, there is literally no guidance how to successfully manage the process of creating, changing, and using Enterprise Architecture.

This guidance is crucially important. Without it, it is highly unlikely that an organization can successfully produce a complete and enforceable EA for optimizing its business value and mission performance of its systems. For example, effective development of a complete EA needs a corporate commitment with senior management sponsorship. Enterprise Architecture development should be managed as a formal program by an Enterprise Architecture Department that is held accountable for success.

Since that EA facilitates change based upon the changing business environment of the organization, the enterprise architect is the organization’s primary change agent.

Effective implementation requires establishment of business and system compliance with the enterprise architecture, as well as continuous assessment and enforcement of compliance. Waiver of these requirements may occur only after careful, thorough, and documented business case analysis. Without these commitments, responsibilities, and tools, the risk is great that business changes or new systems will not meet organizations business needs, will be incompatible, will perform poorly, and will cost more to develop, integrate, and maintain than is warranted.

For more info about this go to the book webpage.

Download book index here: Book index

For ordering the book directly at the Publisher, go to: http://www.trafford.com/07-2553

Ordering this guide directly at the website of the Publisher is the easiest and fastest way of getting this guide.

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.