If you haven’t read the book, and you’re interested in operating at the enterprise level, do so. Now back to the session.

Not all organizations really operate as a single business. If you market to different customer groups, for example, you’re effectively operating multiple businesses. One of the ideas in EAS is that there are a number of operating models that you can adopt as a business that determine how integrated your technology really needs to be.

In order for EA to be really effective in helping to shape business strategy, there should be an understandable diagram that boils down how the IT infrastructure works in a way that the business executives can not only understand but actually use to help them leverage the IT infrastructure for business benefit.

Oops. Fire Alarm. Richard is trying to talk over the alarm which is not resulting in a very comprehensive presentation, though not his fault.

Core diagram doesn’t fully describe EA at an actionable level–it’s there to help articulate it to the business. Alarm now over.

A business application is the automation of one or more business processes or capabilities. Do not combine processes and applications in the core diagram–it must be clear which is which.

More alarm. Session cancelled, even though alarm finally shut down.

In order to be successful when driving change, you need to make sure you do three things:

1. Listen authentically.
2. Create and communicate a vision for the organization
3. Focus on success and orient yourself towards business goals.

He adds “Organization Architecture” to the usual domains of EA, which has to do with how ready the organization is to accept change and the way in which it processes a proposed change. Building relationships within the business is key for ongoing EA success. YOu can’t build trust by speaking to people twice a year–you have to stay engaged with them and understanding their needs. That means genuinely working with people, learning to speak their language, understanding that change is uncomfortable, and striving to understand their position rather than sell yours.

Another key to success is to have some quick wins. Success reinforces itself. Acronym for 6 steps to pragmatic change: LISTEN (Learn, Interpret, Shape, Tactical Planning, Enable, New Road). For EA they have a 4-step roadmap:

1. Engage and Model
2. Collaborate
3. Enable
4. Prove

Created a Book of EA Value (template for capturing it). Could be useful to BAs too. Five steps:

1. Opportunity (where is value captured/created)?
2. Enter EA (how has it contributed to creating business value?)
3. Continuing success (how is it continuing to contribute? Is it controlling costs? What measures are being used to ensure results?)
4. EA Investment (What was required to achieve this value?)
5. Bottom Line (What are the results? How did this help the organization?)

What does it mean to be agile? There’s no agreed definition, but Scott has 5 criteria: produce value for stakeholders on a regular basis, do continuous validation of the product, work closely with stakeholders, self-organize, and regularly reflect on and measure team effectiveness. Scott makes the point (which is one I also have made to BAs) is that you never, never, just build software–you are always changing the organization, its processes, business rules, and so forth when you bring in a new system.

Now Scott is saying that the argument that stakeholders are too busy to work with IT is nonsense. If that’s true, it’s saying that the ROI from her doing her job is higher than the ROI of building this IT system that will make her more effective. I agree with Scott on the implication, but I think his confidence in the business tradeoff of supporting software development may be overly strong (or that businesses can and do just think about ROI). Maybe more on that in a separate post.

Scott ran a survey of self-identified agile teams to find out how many of them were doing all these things. Result:

Value: 94%
Validation 87%
Stakeholders: 95%
Self-organization: 56%
Improvement: 88%
All 5: 53%
Everything but self-organization: 72%

In other words, many people claim to be agile but aren’t.

IBM has their own agile lifecycle that incorporates Scrum concepts but includes three major phases: Inception (before software is built, focused on estimation and developing enough requirements to understand overall scope), Construction (building the product) and Transition (handing it over to production).

This process includes some additional roles, but Scott argues that Agile teams require “generalizing specialists” to be effective–that is, people who can play more than one role even if they focus on one.

Now going through survey results. Basically, iterative and agile approaches have similar statistical success rates. Waterfall is about the same as having no process at all. Regardless of method, larger projects have lower success rates. However, for a really small project ad-hoc approaches work reasonably well. With distributed teams, agile, iterative and traditional processes work out about the same, which probably suggests that we don’t know much about how to be effective in that situation.

Documentation is the only one where every method produces poor results, although the best documentation seems to come from iterative projects.

Now discussing state of EA. Top goal of EA is to promote a common technical infrastructure. Top results include better integration between systems, IT governance, common infrastructure. It definitely appears from Scott’s surveys that EA in practice is still very tech despite the desire to be focused on the business in the EA community.

A common failure mode for EA is to focus on model development rather than being active in projects.

In most organizations, architecture is set on day one–you’re not going to select a different database for each application. By the way, this is also true of a lot of software requirements. Most books assume you have a green field to do your work, but in practice most work is enhancing an existing system which means that you have to fit what you do into the way those systems already work.

In governance: only 19% said governance was helpful to them, 16% don’t know what it is. Purpose of governance is to make sure that IT investment actually delivers value, is aligned to strategy, and controls risk and change.

Big problem in IT, according to Scott, is that 60% of project teams provide their stakeholders with information about time, budget, or scope that they know is inaccurate or actively misleading.

At low maturity on large projects, an average of 62% of effort is wasted due to requirements failures. Can be reduced to about 2%.

When working on projects with limited process change — for instance, modernization of a legacy application — it’s faster to rely on tools and surveys to find out what stakeholders are doing. Traditional approaches take too long. On large projects they looked at the transactions people were performing and had an SME walk them through the work itself.

Overall, I may be the wrong audience for this pitch–not a lot that was new to me and some concrete examples of doing things mentioned in this session would have helped.

The panel is being moderated by Ken Russell (Cisco).

Siva said that one of the big drivers in acceptance of EA at Cognizant was the potential for it to help control operational risk. Scott suggested that you can’t really claim that your organization gets the value of EA until the group has survived three re-orgs. Zachman said that in general, business managers don’t see the value of EA or understand why it’s valuable. EA is a long-term investment into the growth of the organization–it won’t pay off in the very short term but helps the organization be more resilient to change in the longer term.

Jennifer says that EA IS a technology discipline and the job isn’t to make business executives get involved in it. The real job is to talk to the business in their own terms. Scott disagrees with this and argues that it’s irresponsible for executives not to understand IT these days (I would agree with that one, actually–while my IIBA role is definitely on the “business” side of things I have to regularly consider what IT enhancements and systems we need to implement).

Zachman discusses the challenges of communication–in his framework the discussion takes place along the boundary between perspectives (the rows) and in general you can only effectively converse one level up or down. Not sure on this one because I think BAs at least need to operate across multiple roles.

Based on survey of CEOs, biggest problem most enterprises face is change. So why is there nobody explicitly in change of change management?

Change comes from many directions. Jennifer discussed the challenge faced when the CEO bought an iPad and wanted to deploy it to all the sales folks–the existing apps and workflows just couldn’t get ported over.

Scott suggests that one way to get insights is to talk to other people at the conference. It’s likely that most people at this conference are suffering the same problems because most attendees are working from a common set of assumptions, and that most of the ideas about how to run IT come from the US DoD back in the 1970s.

Siva is talking about the tendency in IT to want the newest toys and tech whether or not that meets a real business need. This is something that generates distrust in the business, because the value to them is unclear (witness the reluctance of businesses to move off of Windows XP).

Panel is now discussing the difficulty of bringing change to organizations. Change is uncomfortable even when it’s clearly for the better, never mind when the benefits are ambiguous. Change is hard unless there’s something clearly pressing for it.

Concept of “alignment with the business” is somewhat problematic. Panel agrees that we EA needs to think of themselves as part of the business, not a separate thing.

More discussion on the business understanding technology question. Benefit to the business execs is that if they distrust IT, they should be willing to do the work to understand it and make it effective. IT people also tend to focus on teaching the business the wrong things–the details of how IT works rather than the context and uses of technology. What they need is enough context to understand the implications and impact of their requests, not get sucked into detailed decisions.

Data management is a major challenge for Manulife, a company that has grown through acquisitions. Because of that, there are a lot of different systems in use and a significant data management effort is required to keep that information consistent, let alone allow those systems to communicate and transfer data.

Master Data Management is a smaller component of information management, which also includes document management, records management, KPIs, metadata and more. MDM has the problem that it sounds simple but there are a lot of operational challenges with implementing it.

The challenge in MDM is not the IT side of merging data (although that is real) but really that each business unit has its own idea of the meaning and relevance of certain information. Because the data is used for different reasons by different groups, consistency is hard to achieve.

Needs to be built on top of a lot of other capabilities, from BPM down to the basics of ensuring that your data is secure, accurate, and that effective models are defined. You need a relatively mature set of practices in place in order to be able to do things effectively.

Basic structure of MDM IT architecture in Manulife is that all applications use a master distribution application to communicate with other applications. That application accepts and delivers information to other linked systems in a format that system can consume.

Data governance was built from the bottom up…starts with putting in some controls in each operational group. Once their data is effectively managed, you can address problems in the larger business unit, then the higher-level strategy, then ultimately engage C-level executives to set a long-term vision.

One major problem with projects is too much focus on the capabilities we deliver and not enough on the business benefits. Common problems include:

1. No disciplined effort to ensure benefits actually captured.
2. Project portfolio planning done once a year.
3. Big commitments made too early.
4. Bad projects not stopped.

In the absence of a strategy, there’s no need for an architecture.

Four Rs of Portfolio Management:

R1. Are we investing in the right things?
R2. Are we doing them right?
R3. Are we executing them well? (role of PMO)
R4. Are we getting the benefits?

Historical focus has tended to be on only R3.

Why do prioritization? Need to maximize benefits given constraints. Financial, time, resource, knowledge, and absorption constraints all relevant.

Three groups participate. Decision-makers, prioritization committee (who collect info for decision makers), workers.

Now talking about how prioritization is done. Is basically Enterprise Analysis. Big challenge is figuring out how much analysis is useful. An organization should have a “point system” to score initiatives and consistently use it to assess candidate projects. Some projects will get approved even though they don’t score at the top. This should be expected.

Initiatives produce capabilities that the organization uses to produce business results which support organizational goals and objectives. In some cases you will need to create a capability in order to even launch a desired initiative.

According to Zachman, the problem is that IT can’t deliver without EA. IT people bring the ability to draft and describe the structure and systems of the organization. This is a core skill that can’t go away, even if you outsource everything. Enterprises are extremely complex structures that can only be understood through the use of models. He views the role as essentially “business engineering”.

The word “Enterprise” has two crucial implications. The first is scope: EA must always view the enterprise as a whole and start from the big picture. Unless you know the broad purpose of the architecture, the individual pieces will be unable to go together. The second is the context–the purpose of EA is to engineer enterprises, not to build IT systems.

The challenge for EA today is that it’s increasingly hard to control an enterprise from a top-down perspective. New technology is pushing control outward to individual business units and to customers.

EA is not a big, monolithic, static and inflexible design. EA is not the enterprise–it’s a representation of the enterprise that contains enough information for someone to construct an instance of it. “Architecture is the set of descriptive representations describing an object”.

If the object you are trying to create is simple enough that you can see the entire thing at once and it will be stable, you don’t need architecture. If it’s complex, you can’t understand it in its entirety, and it will change over time, you do. Architecture is necessary to deal with complexity and change. If you can’t describe something, you can’t create it, and if you don’t have a description, you can’t predict what will happen when you make a change.

No single representation of a complex object, like an enterprise, can possibly be complete. You need a set of representations covering Why, What, Who, Where, When, and How. These questions should always be answerable–sometimes we fail to ask them, though. In order to deal with complexity, abstract out one thing at a time. In other words, when building a process model, don’t simultaneously revise the organizational structure, supply chain, and other factors. (By the way, I’m trying to keep up here–Zachman is talking as fast as an auctioneer here). If you look at one type of model at a time, you can see the whole set of them. The challenge is that manufacturing, as opposed to engineering, tends to want to see the whole set of things at once.

Breaks it down as follows:

A. Bills of Material (What) – Inventory Models
B. Functional Specs (How) – Process Models
C. Drawings (Where) – Geographic Models
D. Operating Instructions (Who) – Work Flow Models
E. Timing Diagrams (When) – Cyclical Models
F. Design Objectives (Why) – Motivation Models

In order to do engineering, you also need a set of perspectives for each of these. He lists six perspectives as well:

1. Scope Boundaries (Strategists) – Identificaion
2. Requirement Concepts (Owners) – Definition
3. Design Logic (Designers) – Representation
4. Plan Physics (Builders) – Specification
5. Part Configurations (Implementers) – Configuration
6. Product Instances (Operators) – Instantiation

Zachman’s approach was to try and find out what people who did architecture (buildings, not EA) thought it was and then to see if that could be applied to the enterprise.

The amount of detail required for the architectural description depends on how clear the owner’s vision is. If they know what they want and can describe it in detail less documentation is required. However, if they don’t know, you have to drive out information to get them to express what they’re looking for. Each audience has their own view of the architecture, in line with the level of detail they need.

Zachman’s goal was to define the total set of representations needed to fully describe an enterprise. From my understanding of his keynote, he’s not so concerned with integrating them. No one comprehensible model can capture everything. That set is, in his view, the entirety of Enterprise Architecture and if you’re not doing all of it, you’re not doing EA. Zachman’s framework is an ontology, not a methodology. It just says that these things must exist to have an enterprise architecture. He’s comparing it to the periodic table–it tells you the basic primitive models that you have, but how you combine them is something he doesn’t try to address.

Question was asked about an example. Zachman’s reply is that you can’t have an example of his framework because it’s an ontology–you need to build on it to have a methodology, and a methodology can produce an instance. The framework just tells you that these things need to be produced somewhere in your method if you want to actually have an architecture.

Final thought from Zachman is that we’re reaching the point now where the ability of an enterprise to define its architecture is going to be a critical factor in its long terms survival.

So, based on my own experiences and preferences, here’s some advice I would give.

First, adopt a writing style guide for use cases. There are really two that I’m familiar with: Alistair Cockburn’s and Bittner and Spence’s. I find that sticking closely to a set of guides for writing the use case tends to help create better requirements (this is true with modeling notations as well). Yes, sometimes you just want to slap down some content, but my experience is that following the rules often forces me to ask “exactly how am I supposed to model this particular step” which often leads me to realize I don’t understand it as well as I thought.

Which of the two should you use? Well, that’s up to you. In my experience, Cockburn’s style tends to be preferred by developers, Bittner and Spence’s by business users, but as always YMMV. Bittner-Spence has one concrete advantage in that the way it groups alternate flows in scenarios and links them to named extension points makes it easier to pull out some functionality for future iterations.

Second, keep use cases small. I have rarely found a use for “business use cases” except as a scoping mechanism. I use Alistair Cockburn’s “coffee break” test. That is, a use case should be something that a person will sit in front of their computer and can do in a single session, and once complete, they could go to the bathroom or get some coffee. If you’ve got multiple primary actors, or the use case takes days to complete, it’s too big. Many business interactions involve multiple use cases and that’s fine.

To give examples from IIBA, Become an IIBA Member would be a good candidate for a single use case, because it’s a single transaction. Become Certified by IIBA would not be. That “business use case” would consist of several use cases, perhaps the following:

• Capture Applicant Personal Information
• Capture Applicant Education
• Capture Applicant Work Experience
• Capture Applicant Professional Development
• Capture Applicant Reference
• Provide Reference for Applicant
• Complete Certification Application
• Review Certification Application
• Audit Applicant
• Register for Certification Exam
• Take Certification Exam
• Appeal Certification Decision

So that’s 12 use cases, maybe more if I sat down and really reviewed the process or we decided to split things up differently for some reason. If I was doing this for real, I’d probably also look at some included use cases and some others might become extensions.

OK, I think that’s enough for a Sunday. I’ll come back to this later.