Enterprise Architecture Journal

The Carrier

2008-04-28T12:56:00.004-05:00

Hello again,

Last night I watched the two-hour premier of an interesting docu-drama on PBS called Carrier. I really enjoyed the show as they explored the day-to-day lives of about a dozen sailors and Marines on board the aircraft carrier USS Nimitz. Fascinating stuff and I think a real tribute to the wonderful men and women of the Navy and Marines who serve our country so selflessly ... and more episodes to come.

I almost wish they had been on board the USS Enterprise, as it would have made the analogy that I am about to float (pun intended) a little more neat.

As you may have guessed, I'm about to compare life on board an aircraft carrier as analogous to the activities -- specifically IT activities -- in any organization. The aircraft carrier as a framework for all of this intense and sometimes unpleasant activity seems a lot like Enterprise Architecture. Bear with me...

On board the ship, they explored the ins and outs of the various ranks of sailors and Marines. Each had a role, everything was very compartmentalized, and some jobs were outright dangerous. Some served the food and some loaded ordinance on F-18's. Personalities were involved. There were different ranks and privilege levels. Personal lives affected performance and focus. The people there loved their jobs, mostly. Sounds a lot like your average IT shop, huh?

The architecture of this enterprise was the aircraft carrier and the structure and rigor associated with delivering the mission. Similar to any Enterprise Architecture, the system of interacting, the reusable parts that overlapped and shared the same context, was designed to deliver the mission. As long as people stayed with "the plan," the architecture functioned as it should. When someone got outside the plan, there was a price to pay. Like on the boat, people could choose to prematurely jump ship, but would quickly find themselves over their head in the deep blue sea of tactical and unconnected projects.

Not to trivialize the actual life on an aircraft carrier where people could lose their lives if discipline and governance failed, the loss of discipline and governance in terms of an Enterprise Architecture plan analogously results in failure to achieve the intended outcome. Not everyone on the boat understood or agreed with the Mission, but they were all very dedicated to it. How many of us could say that about dedication to our architectures?

This is probably a bit of a trite analogy -- perhaps a bit over-simplified -- but I thought it deserved a shot. In any case, I really enjoyed the show. Kudos to PBS for supporting the men and women of our armed forces!!

Don't Fence Me In

2008-03-24T14:00:00.011-05:00

According to Andrew Clifford in his Simple IT blog, no matter what your specific definition of IT Governance (ITG) is, all the definitions have the following qualities in common:

Control of the work.
Co-ordination between different pieces of work.
Measurement of outcome.
Compliance with internal policy or regulation.
Justification of spending.
Accountability and transparency.
Connecting with the needs of customers, the broader organisation, and other stakeholders.

So what if control, coordination, measurement, compliance, justification, accountability, and transparency are a bummer for you? What if you are a cowboy who likes to personally ride each missile out of your very own silo?

Of course, the Sundance Kid would say that the folks at Deloitte are nuts when they assert that the right blend of IT Governance is the key to getting the most value from IT. Why on earth would an organization want to decide WHERE to go and then collectively MAKE SURE that actually happens?

Oh, give me land, lots of land under starry skies above,
Don't fence me in.
Let me ride through the wide open country that I love,
Don't fence me in.
Let me be by myself in the evenin' breeze,
And listen to the murmur of the cottonwood trees,
Send me off forever but I ask you please,
Don't fence me in.

Just turn me loose, let me straddle my old saddle
Underneath the western skies.
On my Cayuse, let me wander over yonder
Till I see the mountains rise.

Yeee haw.

Now that my tongue has nearly poked a hole through my cheek, I can seriously say that I do not subscribe to Cowboy Architecture. Maybe once, but not today nor tomorrow. As an architect, I have come to understand that decisions are important. Good decisions based on strategic goals and what Peter Schwartz calls the Long View. As an Enterprise Architect, my goal is to help shape technical direction for the Long View and encourage remembering our decisions. Otherwise every IT decision is like herding cats.

Whether its governance by committee or governance by strong leader, governance needs the right environment to work, especially in Higher Education. A survey taken of higher ed CIOs asked what stands in the way of governance (see slide 7). The top three barriers are as follows:

Decentralized / informal culture ... 41.6%
Lack of participation from necessary parties ... 40.4%
Governance insufficiently coordinated ... 30.8%

To keep with our metaphor, The Lone Ranger (although he wasn't really a cowboy, per se) rides again, it seems when it comes to undermining IT Governance (ITG).

So what contributes to ITG a success? Hint: Go to slide 12.

The short answer is PEOPLE, with Support of Executive Leadership (63.9%) leading the pack of reasons.

To summarize, if the references we cite hold any water, Executive Leaders that value...

Control of the work.

Co-ordination between different pieces of work.

Measurement of outcome.

Compliance with internal policy or regulation.

Justification of spending.

Accountability and transparency.

Connecting with the needs of customers, the broader organisation, and other stakeholders.

... really have the destiny of their IT organizations in their hands. The key is to use ITG to achieve these goals.

Make decisions, remember them, shoot for the long view over short term bull rides and rodeos... git along little doggie!

Partnering, Procurement and Persuasion

2008-03-21T10:48:00.003-05:00

Hello again,

My colleagues and I just returned from the Educause Midwest Regional Conference where we presented some of our progress in the last year of our Enterprise Architecture program. The presentation is entitled, "Enterprise Architecture: Partnering, Procurement, and Persuasion" and the slide deck can be found be clicking here.

In the early stages of the Enterprise Architecture program at SLU, we've had to use the tools available to us to make a difference. As Jim Phelps pointed out in his presentation, this is fairly typical of EA in higher education - flexing and adapting the practice of EA to achieve the goals of a unified architecture program.

At SLU, we've partnered with the ITS Business Office in support of the IT procurement process. We've helped clarify standards and we've helped analyze out of the ordinary procurement requests. We fostered an RFI and RFP process which has led to a change in procurement practices for servers and storage. Outcomes of this effort have included implementation of a Unified Core Computing environment and about $2 Million in savings for SLU. We've weighed in on various architectural and standards issues, helping persuade decision makers and developers to support the "to be" architecture suggested by strategy. It has been a heck of a year.

Nonetheless we have a long way to go. Management support of architectural governance and access to strategic planning opportunities continue to be challenges. The first issue has a lot to do with organizational maturity. TOGAF has a lot to say about architectural maturity, wherein I think we probably exist at Level 1.

Level 1: Initial

Informal IT architecture process underway.

Processes are ad hoc and localized. Some IT architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.
IT architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
Minimal, or implicit linkage to business strategies or business drivers.
Limited management team awareness or involvement in the architecture process.
Limited operating unit acceptance of the IT architecture process.
The latest version of the operating unit's IT architecture documentation is on the web. Little communication exists about the IT architecture process and possible process improvements.
IT security considerations are ad hoc and localized.
No explicit governance of architectural standards.
Little or no involvement of strategic planning and acquisition personnel in the enterprise architecture process. Little or no adherence to existing standards.

I also found an interesting extended maturity scale that describes negative levels of maturity. Scary to think in some ways and in specific instances we may be below zero in our architectural maturity.

Brenda Michelson gives some excellent clues for success in her blog, elemental links. Here's an excerpt:

Keys for Success

No doubt, individuals in enterprise architect positions are extremely self motivated, and in their minds, success is never in question. However, there are things CIOs can do to ensure their enterprise architect (and architecture) are successful. Here are seven actions you can take:

• Make Room at the Table for Architecture Leadership. The architecture leader must have a seat at the CIO’s table in IT leadership and business leadership settings. The architecture leader, particularly one with an architecture background, will listen and contribute to the discussions with an enterprise architecture perspective. Don’t filter his/her information through a leader with a non-architecture focus.

• Set Shared Goals for Your Architecture, Project and Portfolio Leaders. Reduce the natural tension between architecture, projects, and portfolios, by setting some shared goals related to initial productivity, asset utilization (re-use), and enhancement productivity.

• Fund and Resource the Architecture Team, Early. To realize the architecture, the architecture team must have development and engineering resources. Set this team in motion ahead of the dependent projects.

• Transition the Architecture Assets to Operations. As the architecture portfolio is built out and incorporated into projects, transition the day-to-day operations of the resulting tools and infrastructure to operations teams. Don’t lose your architecture team to operational tasks.

• Integrate Enterprise Architects and Project Teams. Reduce the natural tension between enterprise architects and project teams by having them collaborate on projects. Seed enterprise architects into your project teams, particularly in pilot situations. Loan talented developers and engineers to the architecture team, to build out the architecture.

• Sponsor an Architect’s Forum. Bring all of your IT architecture talent (enterprise, domain, technology) together periodically to exchange ideas, discuss challenges, and tackle your toughest problems. Leverage their collective brain power. Create a community.

• Encourage Enterprise Architects to “Feed Their Brains.” For enterprise architects to stay on top of their game, they need to continuously explore, stretch their boundaries, and sometimes, just sit and think. Recognize this is part of the deal. Be patient when the areas they explore don’t have an obvious connection to your business or technology plans. Trust their instincts.

***

Good goals, don't you think?

BA and EA

2007-11-08T09:38:00.000-06:00

Building and maintaining relationships are a VERY important part of the ongoing ability of Enterprise Architects to do their jobs. Take a look at Figure 7. this IBM document -- it kinda says it all.

If EAs don't have their finger on the pulse of the organization, including business requirements and strategic direction, then it will be impossible to validate architectural requirements and strategic context.

I've just returned from a four day Business Analysis Boot Camp (ASPE) in which it really became apparent that BAs are engaged in many of the same relationship building and requirements gathering activities as EA. Business Analysis even involves an "Enterprise Analysis" phase. Kinda spooky. By the way, the boot camp was great! If you do the course, see if you can get Bob Keith as the instructor -- top notch!!

The stakeholder interview and documentation approaches offered in the BA class (and in my earlier Systems Analysis and Design courses) are very similar to what Dana Bredemeyer and Ruth Malan teach in their EA workshop.

BA is a strong presence in the Business environment and even has it's own Body Of Knowledge (BABOK) like Project Management's PMBOK (can't get it for free anymore) and offers certification through the IIBA. In many aspects, it's been around a lot longer and has a lot more exposure than EA.

So, what is the difference between EA and BA?

The Answer: Context.

While BA and EA both claim to be the "bridge" between "the Business" and "IT" and do rely heavily on iterative requirements gathering and validation, the fundamental raison d'être of each discipline is quite different. BA seems to get engaged because of a project or initiative or idea; EA is engaged despite projects, initiatives, or ideas. While BA's Enterprise Analysis phase certainly looks at strategic context, its a snapshot in time relative to the project at hand; EA's enterprise approach is to provide living context across projects and across time. If an EA is involved in requirements gathering in a project, you can bet that project is a strategic differentiator for the organization. Governance of architecture through formal frameworks (like TOGAF, or E2AF is also a unique aspect of EA.

Its not surprising there is confusion regarding the differences and overlaps of EA and BA. Wikipedia even says that BAs can be architects!

Here's an interesting back and forth between EAs and BAs, including a comment from yours truly.

It seems like one challenge for Enterprise Architecture -- especially in immature organizations -- will be staking a claim on the piece of requirements gathering and relationships that belongs to us, while not bruising relationships with our friends in Project Management and BA. BA can be a valuable partner with EA programs, if the relationship is established early.

Interesting new sites...

2007-09-22T12:41:00.000-05:00

You might want to check these out...

http://www.architectbootcamp.com/

http://www.bredemeyer.com/links.htm

http://www.enterprisearchitectureblog.com/

I'll be adding these to the links section...

jh

Architecture Advancing

2007-09-11T16:11:00.000-05:00

September, already!

Architecture keeps advancing here at SLU and the Enterprise Architecture team is involved in activities that we believe are adding great value. Some of the things the team have been working on aren't classic "EA" as described by our friends at Bredemeyer and others, but they do hit strongly upon the people, process, and technology themes that do add competitive advantage for the University.

The Architecture Review Board (ARB) is chartered and has begun to meet weekly, just following the Change Control Board (CCB) meeting here. The ARB has adopted a short list of Principles by which to manage, and just today adopted an "input" form with accompanying documentation that will be required for Architecture Review. This is a pattern similar to what is posted by our friends over at MIT and other schools. :-) MIT's Architecture Group (ITAG) has a very impressive library of EA artifacts that have been very useful in considering direction. The TOGAF and E2AF materials have also been useful perspectives. The NASCIO maturity model has been helpful in taking "weather checks" of where we are in terms of organizational maturity. Our documents will be posted very shortly to the SLU EA site, which we are the process of re-vamping. Our ongoing approach will be to fine-tune the process as requests roll-in.

My colleague, John Ashby, has also architected a business process to channel review when "hosting" products (servers, storage, etc.) -- primarily those affecting the central ITS data centers, enterprise standards, and procurement agreements -- come to our attention through purchase requisitions. It is still a common occurrence here at SLU, that the first time anyone in IT governance becomes aware of a server purchase is through a purchase requisition that comes through our business office for review. John as created a "host review" process that utilizes a survey tool we already have on campus to ask some high-level questions. The answers to the questions can then form the basis for additional in-depth review, including review by the ARB. This process was just ok'ed by our CIO and has begun to fix a very old problem.

Open Posting

2007-07-02T13:14:00.001-05:00

Hi,

I've changed the settings on this blog so non-members can post. You will have to confirm an image and non members' comments will be moderated.

I want to encourage as much discussion as possible here!!

jh

June 2007

2007-06-25T16:40:00.000-05:00

I've noticed that Google has been delivering a lot of hits to this blog. Welcome to all of you who've landed here looking for information about Enterprise Architecture!

I wish I could say we were an authoritative source on EA, but we are learning. As you may have surmised, we are a small "EA" Shop at a Midwestern University. None of us are experienced EAs, but we have been exposed to some really great concepts through the Bredemeyer EA workshop referenced earlier in the blog.

We're starting small, and are currently assisting the ITS division at SLU with some documentation and process issues. We euphemistically have called this our "getting IT's house in order" phase. One of the key pieces we did off the bat was to form an Architecture Council, which I chair. This is comprised of 19 domain or "functional" architects from throughout ITS. We use this forum as an information-exchange opportunity, fostering "architecture think" over "project think" or any other kind of "think." This is a challenge as "architecture" as a practice is fairly new here.

The council has made some strides in documenting our de facto technical standards in a document that we call the Product Item Master, or "PIM." This document is a work in progress of course and exists as a multi-tabbed Excel spreadsheet. The primary purpose of the PIM is to give us a basis for managing the "lifecycle" of our technical products, which hasn't always been done very effectively here.

The council has also proposed several "variability reduction" proposals. Only a few have been fleshed out, but all will be formed into a business case document that will be presented to our CIO. One in particular represents the consolidation and management of 10+ undermanaged MS-SQL servers in our environment.

Again, this isn't EA in the truest sense, but I do feel we are setting a business context and building relationships with business decision makers here that will be needed if we ever do "real EA."

If any of you are just starting out in EA, please leave your comments and experiences.

More next time on our forming "Architecture Review Board" or ARB!

jh

Long Overdue Update

2007-04-03T20:20:00.000-05:00

Fast Forward about a year....

Hello, world... again.

A lot has happened in the past few months in the Enterprise Architecture domain at Saint Louis University. Since I last posted snippets and notes from the Bredemeyer conference last year, we've come a long way.

Most significant is the addition of another Enterprise Architect to our team. John Ashby comes with a wealth of experience (17+ years) from the "academic side" of the house. His keen sense of strategy and business mind has created a wonderful context in which we have continued to build EA @ SLU. John will be attending the Bredemeyer EA workshop in late spring. So, our team now consists of Kevin Ballard (the Chief Architect) and the two EA's (John and Me).

I don't believe I mentioned Kevin Ballard in earlier postings, although he was my boss at the time of the earlier Bredemeyer workshop. Kevin heads our EA unit but is also the head of the BI and DBA (Oracle) team here at SLU. He has a wonderful business perspective and is very respected in the organization. His corporate background has added to the dynamic context I mentioned earlier. (Enough pandering to the boss!)

John, Kevin and I recently presented our "journey" so far of creating an EA program at SLU at the Educause Midwest conference in Chicago. The presentation was well received. The presentation and related links can be found here.

At the conference we ran in to Jim Phelps, Senior Architect at the University of Wisconsin - Madison. He got us involved in ITANA, an Internet2 group focused on IT Architecture in Academia. Please check it out here.

Welcome Workshop Participants

2006-09-15T08:46:00.000-05:00

I've shared this url with my classmates, so maybe we could get some discussion going here, even after the workshop.

Welcome to everyone! And thanks to Dana Bredemeyer for the fantastic workshop!

Jim Klempner took pictures of the wall charts from the workshop. They are now posted here for your use and enjoyment.

Dana suggested we also visit Ruth Malan's blog and that of Grady Booch.

I created a Yahoo group to facilitate/archive storage. It's probably a better forum for discussion (listserv/files) than this blog. Please feel free to sign up. Click here to join.

Or send a blank email to ea_discuss-subscribe@yahoogroups.com.

...

Day 2 - Part II (The Vision)

2006-09-14T21:05:00.000-05:00

In order to help stakeholders see a Vision of how strategy can translate into Architecture, the EA can use a Cover Story Vision chart. This is another grahical tool from Grove which can be seen here.

The tool is intended to motivate and create excitement for a particular architecture decision(s) or capability(ies). And to illustrate alignment with an architecture.

On the left of the graphic is a dummied up version of a publication important to the company. The example of the Wall Street Journal was used. The front page would display headlines important to the success of the company. Examples for the Global Broadcast ficticious company included "GB Best Company to Work For in South America" and "Global Broadcast is market leader in innovative technology."

On the right, a page listing the architectures/capabilities required to make this vision come true are listed. In our example, we came up with... "Complete Customer Model (CCM) enables single view of customer. Integrated, Realtime. (Qualities)"

In the chart, you would list quotes from supposed future customers like, "They are amazing!" and "The repair truck was almost in the driveway when I called about my problem."

From this example, we derived two key QUALITIES: INTEGRATED AND REALTIME.

These will be important as we work through the EA toolset using the Global Broadcast example.

Day 2 - Part II (Desired State Interviews)

2006-09-14T20:52:00.000-05:00

Stakeholder profiling, detailed in the last post, is a part of gathering Architectural Requirements -- which come before the gathering of detailed requirements...

In dealing with stakeholders, it's best to interview more than less. Many times "transformative" information is available from those closer to the work in organizations (i.e. help desk worker). Err on the side of talking with too many people.

Always ask the question, is the person I am interviewing going to make a *difference* to the EA work?

In addition to Stakeholder Profiling, a Desired State Interview is recommended.

A desired state interview is more personal and focuses on the individual goals of the stakeholder. This is often done with two EA's present in the room with one stakeholder.

The following questions are typical:

1. What do you want? (now/future)
2. How would you like things to be (now/future)?
3. How do you know you have what you want (now/future)?
4. What is valuable to you?
5. What value do YOU get?
6. What value does the ORGANIZATION get?
7. What are key obstacles? What is getting in the way?
8. What is already right with the system? (key question)
9. What else is important to you?

Many things from the Desired State Interview may not end up in your requirements, but they do help the EA to know the stakeholder better. Also, there may be commonality that comes out from multiple interviews that signals additional requirements.

This also helps identify what the triggers are to make the architecture GOOD, RIGHT, and SUCCESSFUL.

This also helps an EA unfamiliar with an organization to understand the organization better (i.e. dotted line reporting relationships, etc.)

The process of gathering EA data is an ITERATIVE process, so stakeholders may be interviewed and the results shared over a period of time.

Day 2 - Part I (Stakeholder Profiling)

2006-09-13T10:03:00.000-05:00

Howdy! It's Day Two and we are working on Stakeholder Profiling (using a fictitious company). This is an important part of gathering Architectural Requirements...

Here's the process we are modeling from the EA perspective...

1. Identify Stakeholders (who will have a potential impact on architectural decision-making? Sometimes this includes 'boots on the ground' employees.)

2. For each stakeholder, identify the role of the stakeholder.

3. Identify Business Goals
(someone suggested SMART = Specific, Measurable, Attainable, Realistic, and Timely as a way to define goals)

4. Identify System Goals (more granular)

5. State the "value proposition" for each stakeholder.
(i.e. "Future development will work like clockwork...")

A few thoughts...

This seems to be a step we do informally (and incompletely) as a part of our "system development" at SLU, and I don't think I've seen these things formally documented anywhere in our environment...

There are 15 participants here, many from major companies, but I am the only Higher Education Rep here... it is interesting to hear some of the same development and challenges we see at the University level. There was an informal discussion this morning of how important it is to have a Project Management Office (with some control over resource planning) and a strong Change Control process. Someone mentioned "business change control" which I plan to research later.

More later...

:-)

Day 1 -- notes and thoughts

2006-09-13T08:18:00.000-05:00

Hi! It's actually day 2, but day 1 was busy up until bedtime, so here are a few observations from yesterday...

When does an Enterprise Architect get involved?

> When decisions MUST be made first in order to be successful.
> When decisions MUST be made from a whole system view.

**and**

with a MINIMALIST view; only what needs to be done, no more.

EA's should not get bogged down in minor details, unless they are necessary to answer the above questions.

EA's should not be so much of a specific technology advocate, as much as promote BUSINESS VALUE.

The graphic of an umbrella was used with the EA looking at the problem from the top of the umbrella, with functional managers and architects looking at the problem as a "local" issue under the umbrella.

EAs are concerned with BUSINESS CAPABILITIES, which must be a combination of people, process, and technology. They navigate the gap between business thinkers and technology thinkers...

EA Office must interact with strategic thinkers in order to be effective and successful.

In order to have IT alignment with the business, the strategy must be expressed in a way that makes that possible...

The Ideal EA:

1. Must be in "the know" about business strategy and have open lines of communication with the strategy owner.
2. Be involved in enterprise process improvement.
3. Be involved in strategic discussion.
4. Be involved in standards/architecture for corporate data.
5. Have architectural control over key applications.

10% of System Development process should be EA.

The Ideal EA Team should have...

Chief EA *and*
*Chief Business Architect
*Chief Information Architect
*Chief Application Architect
*Chief Technology Architect

EA's should talk about the problems in Business Terms (cost savings, etc.), not in technical terms (duh!).

We also into using a "context map" in order to help develop a strategy. This is a very graphical tool used for "brainstorming..."

(follow up --- go to Grove's website for toolkit... great for facilitate planning and strategy meetings...)

We discussed the structure of a strategy which was described as three circles...

Industry (World Outside)
Competitors (Includes Customers)
Us (Internally)

The visual tools can be used to develop "visions of the future" or scenerios that map and describe trends and forces to the future.

The focus should be on "high impact" and "high likelihood" scenerios

Book References "7 Tomorrows" and "The Art of the Long View" (Peter Schwartz)

Ok enough for now...

Architecture Workshop Next Week

2006-09-08T15:41:00.000-05:00

Hi!

Next week I journey to Chicago to attend an Enterprise Architecture workshop presented by Bredemeyer Consulting. I am very excited about this opportunity and look forward to the insight it will give us to the challenges ahead.

More on the workshop can be found here.

The obvious challenges at this part, are the same challenges we have faced with many of our larger enterprise projects at Saint Louis University including Banner and Billiken Information Shield (an enterprise LAN consolidation and desktop management project). By definition Enterprise Architecture efforts cross organizational and political boundaries and challenge the organization to examine whether our direction is in alignment with current mission and business strategies.

During the workshop there will be an assessment of whether our organization (assuming we mean SLU) meet critical success factors including whether we have a clear business vision and strategic objectives, have an understanding of our core competencies, and how well our EA charter relates to the current state of the architecture.

This should be fun.

Cheers for now.

jh

Hello World!

2006-09-02T14:33:00.000-05:00

Ah, the first post on my architecture journal. Welcome to all visitors!