EA Kickoff

By the kickoff meeting for Ferguson and Bardell's Enterprise Architecture Project, Dan had stopped worrying about whether he was going to get good people for the team. Apparently, the other department heads had wanted to impress the new CIO, and as a result, sent Dan some of their best and brightest. In fact, Dan's new worry was whether all the egos and opinions would fit around the table in his office.

Jenny showed up early. "Not like her boss!" thought Dan with a grin as he welcomed her. Next in the door was Kevin Kennedy, a management fast-tracker sent over by the CEO. Kevin was on the firm's long-range planning committee, where he'd established a reputation for both insightful analyses and the willingness to share them.

Right behind Kevin came Jo Brown, the Assistant COO for Ferguson and Bardell. Jo had been heavily involved in the firm's Y2K effort, and as such had extensive knowledge of the firm's application portfolio. In addition, she was known for her sharp wit and even sharper memos, especially if someone wasn't following the Procedures Manual.

As the group was taking their places around the table, in strolled Dr. Richard Kaplan, who was somewhat of an enigma at Ferguson and Bardell. Dick's first contact with the company had been as part of a consulting team in the late 1980's, doing an analysis of the firm's data storage. Something about him had impressed the IT Director at the time, who had later hired him and stuck him in the development area as an "analyst." Dick had proceeded to teach himself data modeling and data warehouse technology and was often used in the early stages of development projects. He was something of a loner, and seen by some as not too bright because of it. Dan, intrigued to find a Ph.D. working in development, had once asked to borrow Dick's dissertation, which was titled "The Epistemology of Kant: Based on Etymological Studies of His Later Writings." After reading only a few pages, Dan knew that Dick Kaplan was no dunce.

"Morning, all," said Dick, casually putting his pipe in his jacket pocket as he took the last chair. "Sorry if I've held things up."

"No, we were just starting, Dick. Glad you could make it," replied Dan, handing Dick the last of the notebooks he had been passing around. "Did Bill have any problem letting you go to work on this?"

"Well, he groused about it a little, but I gauged the level to be about a 1 on the Bill-O-Meter, so I think it's okay."

Dan laughed. "Jo and Kevin, I hope you had no problems either, taking this assignment."

Jo spoke first. "Not a bit, Dan. They just told me to show up here at 10:00 A.M. for an important project and to give you whatever amount of time you needed." Kevin nodded in agreement.

"Excellent," said Dan as he took his place at the table and opened up his notebook. "Since none of you are up to speed on what we are doing here, I'd like to begin by outlining what this project is about. If you'll open your notebooks, you'll find an agenda. At the top of the agenda, you see that the name of the project is Ferguson and Bardell's Enterprise Architecture Project, or F-BEAP for short. Our job, briefly, is to discover and document our current enterprise architecture and to develop a direction for the future."

Kevin had been listening to Dan closely and taking some notes. Now he stopped and asked, "Okay, I'll bite—what is an enterprise architecture, anyway?"

Dan smiled. "Take a look further down your agenda, Kevin. Our first task is to define EA. Normally, I would have written it on the agenda, but I wanted all of us to write it out manually, so that we could get it locked in our brains a little better and so that we could discuss it as we went."

He stood and moved to the whiteboard behind the table. "I'm going to write the definition out one phrase at a time, and I want you all to copy it onto your agenda. We'll discuss it as we go. Here's the first phrase." Dan turned and wrote A logically consistent plan of activities and coordinated projects on the board and waited while the others copied it down.

"First of all," Dan began, "it's a plan. It's not just a document about what we are doing; it's also a plan of what we're going to do. Within the plan, it is logically consistent. In other words, if we take any two random sections of the plan, they make sense together. And, it covers both activities—things we do over and over—and stand-alone or one-time projects. Everybody got that much?"

While everybody was still writing, Jo asked, "Dan, that's awfully broad. Are we trying to document every activity and every project going on at Ferguson and Bardell?"

Dan shook his head. "An EA is primarily concerned with an organization's Information Technology plans. We're not trying to document everything throughout the company."

Kevin asked, somewhat curtly, "Then why are we all here? I don't know very much about your area."

"As you'll see in a moment, Kevin," Dan said evenly, "each of you has a viewpoint that is valuable and necessary for our EA." He turned back to the board. "Okay, let's keep going." He added that guide the progression of an organization's application systems and infrastructure. to the definition on the board. "See, this is the point of the plan. We will use the document this team creates as a guide for our work in the IT department, both for applications we build or buy, and for any infrastructure work we do. Any questions?"

There were none, so Dan wrote the next part of the definition on the board. The plan should move from the current state to a desired future state… He finished writing and then waited until the others had also finished. "This is an important point. The EA document must both describe where we are now and where we want to be. Implied in this is that we should also put a timetable on that future state; in other words, we have to lay out some goals for reaching wherever it is we want to be. Does that make sense?" Everyone nodded in agreement, so Dan continued. "Alright. This last phrase begins to explain why you are all here." He turned and completed the definition with based on current and projected business objectives and processes. He turned back to the group.

"You see," he said, putting down the marker and sitting back down at the table, "we in IT cannot write our own EA document. We need input from other parts of the firm so that we base our document on the business, not just on what we want to do." He turned to Kevin. "So you see, Kevin, you are here because of your work on the strategic plan of the firm. We have to know those strategic plans before we can develop both our own strategic plans for IT as well as our own tactical plans."

"What about the rest of us, Dan?" said Jo. Dick Kaplan added, "Yes, Dan, I can see the need for Kevin here, but I'm not sure I see where an Assistant COO and a jack-of-all-trades analyst are needed."

Dan replied, "Good questions, you two, but I think the next item on the agenda will help explain each of your roles more fully. Look under the first tab in your notebook."

Four Models with Perspective

In their notebooks, they saw a drawing that showed a triangle subdivided into four sections labeled Business, Application, Information, and Technology. "To be complete, an enterprise architecture is based on four models that each present a different perspective," Dan said. The descriptions of each one are on the following pages. Let's walk through them and look at what each of you are responsible for."

He turned to Kevin. "The Business Perspective is yours, Kevin. We want to know Ferguson and Bardell's broad business strategies along with the plans for carrying out those strategies. Basically, you've got to tell us both how the business works today and how the planning group envisions it working tomorrow. You've also got to help us understand the business processes we follow to run the business. It's all there in the bullet points on that page. Does this make sense to you?"

Kevin seemed somewhat more subdued as he studied the Business Perspective page in the notebook. Finally he looked up and said, "This is a big task, but I think my background with the planning group will help. I can do this."

Dan nodded. "It is a big task, but you wouldn't have been assigned to this team if we didn't think you could do it. And, as you'll see in a minute, we're going to cut it down to size before we leave today."

He then turned to Jo. "Your area, Jo, is the Application Perspective. You are responsible for identifying and documenting the applications and functionality that Ferguson and Bardell uses to carry out the processes that Kevin identifies. In addition, you have to find and document the interaction and interfaces between applications and functions. Again, it's laid out there on the page. Does it make sense to you?"

Jo nodded. "I can see now why I was chosen for this role. My work on the Y2K project, along with the application inventory we did, will be a good jumping-off point for this project."

"Absolutely," Dan said. "Don't limit yourself with that thought, though. Even without the Y2K project, your credentials speak for themselves. I suspect your knowledge of the operations of the firm would have put you here anyway."

Dan then turned to Jenny. "I bet you already know which of these is yours, Jenny," he said, smiling.

Jenny smiled back and said, "Yes, I think I do." She became more serious and continued, "And, as I look over the Technology Perspective bullets on this page, it looks like an excellent job for some sort of asset discovery tool, which, of course, we don't have. So, do I have to gather all this data by hand?"

Dan noted the frustration in her voice. "Jenny, you're right. That sort of tool would make this much easier. But I think that if you check with Jo, you'll find her Y2K hardware inventory will make a good base document for your work. Beyond that, you may be able to gather much of what you need with a well- designed e-mail questionnaire. And I'll talk with Tim about adding the asset management tool to the budget for this year." He leaned back in his chair and continued, "Make sure you don't limit your thinking to just auditing the current situation, though. Look at the definition again and match it up with the bullet points on your page. You have to document the current environment—this is true, but, you also have to plan for the environment the company should have in the future. You're responsible for thinking through and proposing whatever technologies we will need to take this firm where it wants to go strategically. Granted, all of us, including me, are going to have to agree on those technologies, and you are going to have to make a business case for them, but considering the amazing capabilities that technology is bringing us, I'd say you have the most 'fun' position on this project team."

Jenny thought about that a moment and was about to say something when Jo leaned over to her and started singing "Blue Skies." Jenny laughed and said, "Okay, okay, I guess I'm sold. I'll do the grunt work now so that I can do the soaring work later." She looked at Dan and smiled. "And when we break up here today, I'll tell Tim you want to see him about a budget adjustment."

"Fair enough," said Dan. He then turned to Dick, who had been observing the interactions with an amused expression on his face. "So, Dick, you've got the sheet that's left. What do you think of being the one to bring us the Information Perspective?"

Dick studied the Information Perspective page in his notebook and then said, "Well, it looks to me to be the most abstract of the four. I'm supposed to document what the firm 'needs to know' to carry out its processes and operations. I suppose the best way to do that will be to take the output of Kevin's and Jo's work, and then transform it into models showing the information and data needed to make it work.

"I'm also supposed to make a note of all the places we store information and what our data management policies are, if any. This sounds as if it needs to be based on what Jenny does, to some extent. So, all in all, my work is dependent on theirs to start out with. But, as we make plans for the future, their work will be somewhat based on my work, because they will have to consider what data models and data stores we already have in place and how their work will interact with those. Does that cover it, in a nutshell?"

Dan shook his head and smiled. "Dick, I asked for you because of your ability to look at disparate concepts and combine them into a coherent whole. Once again, you have explained it better than the official material did. But even though you ultimately have to base your work on the output of the others, I think you already know enough about the firm's business, processes, and technology that you can begin work on your section now. Do you agree?"

Dick nodded and then asked, "Do you want me to use UML to document this?"

"Ultimately, I will," said Dan, as the others looked puzzled. "For now, though, just begin with some simple tables of data structures and the processes they relate to. Those will be easier for us to grasp on this first version."

Proactive, Reactive, and Versions

Dan turned to the next page in the notebook. "Let's take a moment to look at the direction of process and priorities on this team. Everyone turn to page 6 in the first section."

On that page, a diagram showed the Business Perspective on one side, with an arrow flowing through the Application and Information Perspectives into the Technology Perspective. "This is how EA work is often carried out," Dan said. "First we understand and document the business strategic plans and processes, and then we build applications and information stores to carry out those plans. Finally, we implement the technology necessary to support the applications and information we need."

Kevin leaned back in his chair and said, "Cool! So I bring in the gospel from the business side, and all the rest of you use that to do your thing while I sit back and relax." He smiled smugly and said, "I'm liking this project better by the moment."

Dan thought to himself, "And I'm liking you less by the moment." Concealing his thoughts, he said to Kevin, "That's part of the picture, Kevin. But let's look at the next page for another take on it." They all turned the page and saw a drawing similar to the first, except that now the arrow flowed back from the Technology Perspective, through the Information and Application Perspectives into the Business Perspective. Dan continued, "In today's world, technology is changing so rapidly, with such important implications for business, that only a foolish business planner ignores the impact technology can have on his or her plans. In short, what we want is to have a two-way flow of information throughout all four perspectives, but especially between Technology and Business." He looked directly at Kevin. "One of your tasks, in fact, will be to take the technology possibilities we discover and feed them back into the long-range planning process of the firm. To do that, you will have to listen carefully and learn thoroughly as Jenny, Jo, and Dick share their insights. Do you think you can do that?"

Noticing the tone in Dan's voice in this last sentence, Kevin said in a somewhat more subdued manner, "I certainly will try."

"Good!" said Dan emphatically. He looked at the rest of the group. "I hope you can all see how your part fits into the whole and how important each of you is to the success of this project. Any questions about roles and perspectives?" There were none, so Dan turned the page in his notebook and said, "Alright then, let's take a look at schedule."

When the team looked at the calendar page, there were muttered expressions of disbelief. Finally, Jenny looked at Dan and said, "Dan, I know you said this was a two-month project, but after looking at the tasks before each of us, and at the overall task of the team, I don't see any way we can do this in two months. Two years, perhaps; but two months? No way." There were nods of agreement all around the table. Dan waited a moment and then responded.

"Jenny, if we were going to produce a complete EA this first time, you would be exactly right. But you see, that is the trap that so many firms fall into. They try to document everything in the first cut. In other words, they try to achieve both 100 percent breadth and 100 percent depth. What happens is that by the time they finish, much of the architecture has changed, and they have to go through the process all over again. And because they spend so much time documenting the current state, they never get to plan the future state." He paused, then stated firmly, "This team is going to avoid both mistakes. And here is how."

He moved to the whiteboard, erased it, and then drew a line across the middle. "If we draw what I just said, this line represents 100 percent breadth." He drew another line at the bottom of the board, then drew arrows between the two lines. "And this box represents 100 percent depth." He then drew a line about an inch below the top line. "This is how we keep from drowning in detail. We only shoot for about 10 percent depth this first time around." He put the marker down and continued. "For our documentation of the current situation, we aim for a fairly high level of abstraction—major processes, major infrastructure resources, primary strategic plans. It is up to each one of us to identify the key elements in our area, the ones we absolutely have to pay attention to." Moving back to the board, he then drew three boxes above the middle line. "Once we have a big picture of our current situation, we can pick out two or three big projects or processes that we want to implement, and we make those our priorities for this planning 'season.' That's the end of Version 1 of the F-BEAP."

"How can we do 10 percent and still carry out our tasks?" asked Jo. "I am beginning to see the value of this work, and I'm beginning to get excited about being part of this team. But if we're going to produce some half-baked document that is too general to be of any use to anyone, I want out now. And, if all we're doing is some fuzzy justification for projects you want to do anyway, I don't want to be a part of that either."

Dan realized that Jo's reputation for forthrightness was well-deserved. He thought about her comments for a minute, thinking how to respond. Finally he said, "Jo, I'm with you. My time is too valuable to waste on a project or a document that is just fluff. And, I don't need cover for my pet IT projects. I'm a big enough boy that I can ask for what I want without help from you or anybody else." He noticed that Jo didn't seem fazed by this last comment. "Well, I'm glad to see she takes it as well as she dishes it out," he thought.

Dan went back to his place at the table. "Let me see if this analogy will help. Let's say we need to do some extensive remodeling work on our house. First we'd probably get a high-level picture, an architectural drawing or something to that effect, of the area we need to work on—the current state. Then we'd compile a list of the things we want to change, and based on what seems the most important and cost-effective, we'd decide what we should focus on first. We'd pick out two or three of the projects on our list—the ones that had to be done right away or those that we could actually do in a reasonable time frame, and we'd move forward on them. We'd get whatever additional documentation we needed; but otherwise, we'd do the process well enough to enable us to move forward intelligently."

"That's the key here, everyone. We want to work at a high level so we can get the first version complete in a reasonable amount of time. But the goal is to document the current state just well enough to enable us to plan for the future state, without tripping over any 'gotchas' along the way." He turned to Jo. "Does that make sense to you, Jo?"

She nodded slowly. "Yes, it does. In fact, it's an excellent analogy. When we're remodeling, we're not building a new house. We don't have to do extensive planning just to start. We're already living in our house. It's already built. We could go back and recreate all the plans necessary to build it again, but why? We're better off simply understanding what we have well enough that we can mold our vision of the house in the future based on the reality of the house we have today. Then, we plan how to get from here to there, with some feedback along the way from our friendly neighborhood contractor and her pal the architect," she concluded, smiling at Jenny and Dick.

"By George, I think you've got it!" said Dan, looking around at the others. "Is everybody clear on our goals for Version 1, then?" When everyone nodded, Dan turned back to the agenda in the front of his notebook. "Alright, then, we're ready for assignments."

Getting Started on F-BEAP

Dan pulled some handouts from his notebook and passed them around the table. "What I am giving you now is a listing of the things that I think are part of your EA perspective. Some of them are from the diagrams you've already seen; others I've added based on my months here at Ferguson and Bardell. You may think some are unnecessary; you may think of others you want to add. We can deal with either possibility as long as you can justify your decision to the team.

"Before our next meeting, I want each of you to make a list of all the primary items you can think of under each thing. Keeping in mind our 10% depth goal, go back and rank the items in terms of importance and whether they help to form the foundation of the element. In other words, you want to be sure to include the absolute fundamental items that must be included for Ferguson and Bardell to run. Other items may not be fundamental, but if they're important, include them, too.

Finally, make a first cut at identifying any relationships you see between the items you've listed. The more relationships you identify, the more fundamental that item probably is to the EA. Of course, there is also the possibility that an entire process or two may be unnecessary, which we hope we will see as we move through the project."

"Dan, when is our next meeting?" asked Dick, taking out his personal digital assistant to note the date and time.

"Next Monday, a week from today. That should give each of you plenty of time to write up your first draft. I'd like you to send those documents to everyone by Thursday afternoon so that we can all review them before Monday. Is that okay with everyone? Yes? Good." Dan paused and looked at each member of the team. "I know you know that this is important, and I'm looking forward to seeing what you come up with. I'll see you back here next Monday, and in the meantime, if you have any questions or need any help, just call or come by."

"Oh, I almost forgot." Dan added as everyone rose to leave. "Everyone needs to keep in mind that we are not holding off on developing projects until this EA is completed. We will continue to create new systems and refine our existing systems. Other groups will need to work with us as we architect a solution, to make sure our initial visions for the enterprise converge. Don't forget, we'll continue to refine our environment to reach the desired state and revise the vision as we go along."