The Carrier

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

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

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.

1. 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.
2. IT architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.
3. Minimal, or implicit linkage to business strategies or business drivers.
4. Limited management team awareness or involvement in the architecture process.
5. Limited operating unit acceptance of the IT architecture process.
6. 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.
7. IT security considerations are ad hoc and localized.
8. No explicit governance of architectural standards.
9. 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

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...

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

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

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