© 2002 Bob King, www.rc-king.com
Can you get more than three people to agree on the definition of project architect? How does someone called architect figure out how to add value – or even what to do? Come along as Amy explores different ways the role is defined in her organization and decides what she wants to do as an architect.
Amy began her career as a programmer/analyst; she coded. As she grew in her coding skills, she progressed through senior and lead programmer analyst jobs. She still coded, but tackled more important, difficult and rewarding assignments. And, her programmer peers came to her more and more often for coding advice.
Because she was good at these tasks and because she could get along with people, she graduated into a design position. She described in detail what other programmer/analysts coded. She also managed those programmers on a day-to-day basis.
Now, an important large project, Cloth, is forming to construct the replacement for the application on which Amy has been working. The old application, Papyrus, has been held together with spit and bailing wire over the past 3 years. Customers are restless with Papyrus and looking for a more modern product. Senior management has decided that they have delayed this effort long enough and has funded the project.
Harold, the program manager, has been thinking about Cloth for the past month. He was assigned out of the program office, as are all strategically important projects. Harold knows that his first step is to write the project charter. In the past, this is where he is able to gain a good enough consensus on what the purpose and key requirements of the project are, who the key actors are, how much can be spent, when it must done and how the work of the project should be structured. However, on this project he is having some problems answering the last question.
He has been most successful on projects when he has structured the project to mirror the structure of the application. Since Amy has the most experience of the technical staff that has been supporting Papyrus, Harold has asked her for some help in figuring out what the high level structure of the application should be. Based on that structure, he believes that Amy and he could then come up with a coherent work plan.
He has even offered her the role of architect on the project. Amy was immediately pleased by Harold’s offer and figured that being an architect was clearly a step up for her and a clear step in the right direction for her career – especially with Cloth such an important project to the company.
She and Harold had had a good discussion about what her role would be. He wanted her to work with him to identify the big pieces of the application and what the relationships should be between them. Those words felt good to her, as she knew the shortcomings of Papyrus intimately. She had spent much time thinking about what the ideal structure for replacement application should be. In many ways, Harold’s request of her was just what she was after.
It was Friday, and being a prudent person, she told Harold that she would get back to him after thinking about it over the weekend.
Just before lunch, she checked on the company intranet for a job description of the software or project architect role. She was not surprised when she did not find one; she didn’t think the role had been formalized. She wondered why. Maybe it was because it was a new role. Or maybe it was because the role was not well enough understood.
Then, she remembered that Larry had been the architect of the last big project in the company. He probably had thought about his role. She strolled over to Larry’s office hoping that he would get a bite to eat with her so that she could ask Larry what it meant to him to be a software architect. She found Larry reading a thick book about comparing common object model (COM) and Common Object Request Broker Architecture (CORBA). She’d heard of COM and CORBA and was a little intimidated when she realized Larry must be an expert it in. He was delighted that Amy had an interest in his views on software architecture. He put his book aside as he got up to join Amy for lunch.
Just after sitting down for lunch, Amy asked Larry what he thought having an architecture role on a project meant. “The role of the architect is to answer all the technical questions on a project. You are the most technical person on a project populated with technical people. Your influence will be exactly equal to how much technical knowledge you have about the technologies that will be used on the project.”
Amy was a little dismayed. She had deep knowledge of the Papyrus’s domain. But, because it was built with technology that was 10 years old, she was not up-to-speed with the newer technologies that she knew that Cloth would be implemented in.
Larry continued, “For example, on my last project, the architecture was thin client linked to a backend database through an application and web server. I spent most of my time on that project learning about the app server to ensure that we used it appropriately. I really enjoyed having the opportunity to get under the hood and putting that app server through its paces.”
“How did you know what you were building would solve the original problems?” Amy wondered out loud.
“Oh, you mean the requirements and analysis work? I left that to the analysts. I sat in on the working sessions they held to build the use cases and information models. The principal users were there as well. I got a flavor for what they wanted and answered some questions about whether certain things they wanted to do could be done. In the end, they figured out what the requirements were and gave them to the programmers. I had figured how to structure what we needed on the application server. Then, basically, the programmers inflated the application and database inside of my basic structures based on the modeling done by the analysts. We had a few hiccups along the way and it was in the solving of these problems where I really earned my money.”
Amy had heard of the heroic efforts that Larry and the programmers on that project had gone through in order to get the application delivered. It was delivered quite late – but it was delivered. The final acceptance of the application by users was still up in the air.
“Harold has asked me to take on an architect role on the Cloth project. Any advice?” asked Amy. Larry jumped right in, “You need to stake out your territory quickly. Project managers will poke their noses in anywhere and question your every move if you don’t establish your independence early. It might be uncomfortable at first, but it will pay for itself latter in the project. After the first couple of weeks Lisa pretty much left me alone.”
Lisa was Larry’s project manager. Amy figured she probably should give Lisa a call to get the other side of the story. She thanked Larry for his help.
Amy found herself back in her office. Her head was spinning on the walk back. Larry had always been able to quickly understand esoteric technical products and approaches. She could tell that he enjoyed being the technical oracle on a project. His description of the architect role was dependent on an overriding technical knowledge and skill and actively staking out this territory.
She could sense that he enjoyed an adversarial relationship with the project manager – maybe lording his technical knowledge over her just a little. She admired, and was little jealous of, Larry’s technical skills, but she knew that this was not what Harold was looking for from her – at least not right now. She was little frightened that her architect role might become the role that Larry described. She did not want that.
Amy dialed Lisa’s number and Lisa answered. She described to Lisa her situation and gave brief synopsis of her discussion with Larry. And she asked if Lisa was willing to take a few minutes with her. Lisa was too busy then, but suggested to Amy they meet for a quick drink on the way home. Amy agreed to meet her at Al’s at 4:00.
Sitting back down at her desk, she remembered a voice mail message from a consultant who had mentioned something about architecture. She dialed up her voicemail and found the message. It was from Hank Gainer. His teaser message mentioned something about software architecture and UML. She decided to call him.
Hank Gainer also answered his phone. “I’m on a roll,” Amy thought. Amy described her current situation and her confused state as to what an architect does on a software project. Hank, seizing upon a marketing moment, launched into his spiel. “First, you must lead the creation of use cases along with all that this implies – like figuring out who the users are and what they want from the application. The use cases describe what the system must do to support the users in the accomplishment of their goals. The information from these flow into the creation of the class and interaction diagrams.”
Taking a quick breath, he continued, “Then, depending on how dynamic and large the classes are, you might have to create state and package diagrams. Finally, deployment and component diagrams must be created to physically describe the application. The job of the architect is to manage the process of creating the models – deciding which models need to be created when.”
Amy was dumbfounded. She had heard of UML. She had not used it in any of the work she had done up to now, nor was she aware that anyone in her company had used it. Larry had not mentioned it. She had seen the marketing brochures from Rational and had some curiosity about it. Now, Hank was telling her it was central to the architect role she was considering.
“Wow,” she said, “I didn’t realize that the architect’s role was so well defined.”
Hank seized the opportunity, “Well, I have done this on a number of projects now, so I have been able to define it pretty well. I have been successful doing basically the same things on one project or another. In fact, I have but together classes describing this approach. I am offering the use case class at the beginning of next month. This is where you should start and I just happen to have a few openings. You and some of your team should come.”
“Thanks for the opportunity,” Amy replied. “I’ll consider it.” She quickly hung up before Hank could move on to his next marketing opportunity.
Now, Amy had heard two different descriptions of what an architect does on a project. Both of them offered what she considered to be technically focused approaches. She knew that she must not diminish the importance of the technical side of the role. From past experience, she knew she could talk about and understand technical concepts. She would not have to shy away from these aspects.
But neither of them had really talked about people or leadership; either they took them for granted or they ignored them. Amy realized that by her noticing that this was absent in those descriptions that it was important to her. She realized that she had a choice in how she formed her architect’s role. People and her relationships with them will be an important part of the role that she will create.
Four o’clock found Amy and Lisa at Al’s. Lisa, like Harold, worked in the corporate project office. She had managed some of the company’s most important projects. She was still working on implementing the project that she had worked with Larry on.
“So, you are considering becoming the architect on Harold’s project,” she started. “He’s very good to work with. He and I find the architect’s role as somewhat of a puzzle. We’ve often talked about it. Most technical people are flattered with the title; there seems to be this fascination with architecture. And, it seems, that every technical person and their boss has a different idea of what it is. In some ways, the role provides an opportunity for good technical people to write their own ticket on a project – to do whatever technical work appeals to them. Then, we project managers, are left to pick up the pieces of what is left and to figure out some way to get the rest of the work done.”
Amy certainly saw this was true in how Larry described his role. And, she saw how Hank Gainer had defined the role in a way that probably maximized the earning potential of his skills. She couldn’t really blame either one; they knew their strengths and were playing to them. And, she could see Lisa’s point as well.
“Why does this happen?” asked Amy.
“I have heard it said that software development is still more art than science. With art comes mystery because if there was a formula for it, then any one could do it – not just those blessed with artistic talent.” Lisa looked at Amy and continued, “Excellent technical skills are our industry’s artistic talent and those that possess it cultivate its mystery. I see this in the way that technical people – Larry most recently for me – talk to me. They seem to do their best to use arcane language whenever possible.”
Amy sighed; she knew this was true. She made a mental note: a good architect demystifies the technical aspects of a project.
“I think that Harold has an immediate problem that he wants my help with,” Amy offered. “He wants to structure the development side of the project to mirror the structure of the application. Sounds like a good idea to me and he wants me to figure out the application structure. I am flattered that he feels that I can do it.”
Amy stopped for moment, and then continued, “Lisa, what is your ideal architect?”
“Well…” she mused. “There always seems to be a gap in the project sponsors’ understanding of exactly how the application will work. They don’t need to understand the details, but they should understand the how it works at some level. Usually they don’t. Most of the time whenever technical issues reach the project steering committee, decisions are made without enough knowledge of the real trade-offs.”
Lisa continued, “I’d love to have someone – a partner really – in the project who has the practical knowledge to really understand why we are doing the project in first place, the technical knowledge to deeply understand the issues that are sure to come up, the communication skills to explain them to non-technical people in the context of the real reason the project is being done and the courage to bring them up and deal with them directly as soon as possible.” Lisa paused, lost in the comfort of a nice daydream. “Thanks for asking, I haven’t really thought about it like that before.”
“Is that all?” Amy joked. She looked at Lisa. Lisa smiled back, “One of my rules in life is to ask for what you want and you just might get it. I just hadn’t thought of asking for this before. Maybe when you have finished your project with Harold, we might find a way to work together.”
“I think that I would like that,” Amy replied.
Later, at home, Amy was beginning to understand better what she wanted in her architect’s role. She would exercise Lisa’s rule and ask Harold for what she wanted. But, what exactly did she want?
She was thinking about what Lisa had said. Lisa said that the people who make project level technical decisions and resolve key issues do not always understand the technical aspects well enough. Lisa wanted to work with a technical person who would be able to translate arcane technical concepts into ideas understandable by project decision makers. That translation must not lose the meaning inherent the original technical concepts.
Suddenly, it struck Amy: she wanted to be the meaningful link between project decision makers and the technical people on the project. She wanted technical people to feel that project decision makers understood them and that the decisions made reflected that understanding. Conversely, she wanted the decision makers to feel confident that they had access to all the information they needed in a form they understood and believed to be what their technical staff really wanted to say.
Amy was coming to realize that a project succeeds when it is truly meaningful for all the people working on the project. Meaning, not in the deep meaning of life sense, but meaning derived from doing something that you know is useful and important and understood.
She felt that she would not be the only person who could provide this meaning. Surely the project manager and others on the project provide much of it. But, she began to understand that her architect role was to concentrate on the key technical areas – especially those with some risk – and do whatever is needed to ensure that they are meaningful to everyone with a stake in the project and that that meaning is shared.
She was excited about the prospect of asking Harold to work with her to formalize her role as the project architect around these ideas. She felt that she and Harold could define a role on the project that would be good for her and would provide value to the project and company. She was eager to begin.