The Software Architect and Organizational Readiness
Michael C. Martin
Summary: To be successful, an architect must be able to assess an organization's readiness to change. Implementing organizational-readiness activities in your project plan is above and beyond the technical process of software architecture. The good thing is that it is not a hard process to add into the mix of your development process. (4 printed pages)
When I was a boy, I spent a week or two every summer at my grandparents' house. It was a great break from the monotony of my normal summer vacation—doing the same "summer" jobs (painting the house, cleaning up, preparing for school) for which I was always drafted at home. As soon as you were there, in that quaint west Georgia town, there were no doubts that you were in the summer season. It was always hot there in the middle of summer (they did not have air conditioning), so we had activities scheduled throughout the day to match the level of activity to the heat.
One of my favorite times was the mid- to late-afternoons, because either my grandfather would have me working in his shop creating something (I think we created a lot of sawdust, more than anything else) or my grandparents would have me on the shaded porch playing with the LEGO bricks that they bought me. Every summer, I think we cleaned out every store within 20 miles of that west Georgia town of every LEGO product and, as a result, my creations grew bigger and more complex—object upon object, structure upon structure. It all made sense to me, at the time. I made a lot of things that only I understood. My grandparents never saw the purpose in what I did, but it served its own purpose at the time: to keep me out of my grandparents' hair for a few hours every day.
I think that is also where I got my appreciation of where software architecture is today. It seems that software architecture can all be described in terms of building blocks and components. Today, my "LEGO bricks" are software components, frameworks, IDEs, SDKs, and Commercial Off-the-Shelf (COTS) packages. My role as a software architect is multifold: Choose the components, integrate the ones that I can, and lead the team in creating custom supporting code to link the components in times during which there are no obvious connectors to build something that will benefit the business.
Just as in my earlier summer days, I do not worry about making the blocks fit; it's my job to connect what I can and "glue" what I cannot. I just worry about arranging the blocks and making the blocks "mean something." I (and I am sure that you do, too) get a lot of satisfaction from "building a solution" for my customers, and then watching as my contraption is put to good use by automating some previously inefficient process or enabling a whole new way of interacting between the company and the customer.
I am sure, if you step back and look at some of your more technically successful projects, that you will find similar characteristics. They were difficult, they were complex, they were done in record time and under budget, and there was a party thrown afterwards in celebration of the success. OK, well, at least the last parts of that last thought was always a fantasy of mine, but let's get back to the point. Typically, a well-executed IT project is implemented correctly, and all tests pass and the user signs off on acceptance. But, is the project really a success?
It Has to Run and Be Useful
While you were building the project, did you assess the organizational readiness for the change that the insertion of your new process would cause? Did you build training materials and suitable post-delivery operational documentation, so that the users of the new solution would be able to use your solution quickly—with the least amount of support time needed? Did you think about what impact your solution might have on ongoing support needs for your IT staff and how it affected customers that were a few steps removed from the actual solution, or was it done "just enough" to get the solution in the works?
As a successful software architect, you must get a perspective on the impacts of your solution to the immediate components, the processes, and the immediate "users" or "customers." Yes, your job is to be detailed, focused on thinking through the minutiae and details of the project; but you also must see the "big picture" and be able to help navigate your solution and team around foreseen obstacles. Are you working with your customer and your team to help gain the perspective from their input, as well as to give you a complete picture?
Consider the Entire Life Cycle as Part of Design
This is a good area to think about in the design of the immediate project. But what about the "complete life cycle" of your to-be-deployed solution. Make sure that you take into account the immediate users of the application, that they are well-prepared for the new event. Taking the viewpoint of the immediate impacts is critical to the success of the project. But now, you must lift your head, look up toward the horizon, and ask yourself, "Are the folks who are to take this solution into operation and maintenance well prepared for the transition?"
This perspective from a "crow's nest" of the project team must start at the beginning design phases of the project and should continue well past when the user-acceptance test and project signoff are complete. Some development shops follow some methodologies in which the quality-assurance (QA) team is responsible for watching and enforcing more of these organizational-readiness issues; also, some methodologies call out specific tasks and artifacts that must be created and auditable through the development process, to prove that, yes, these things were thought about at one or more times throughout the project. In a smaller shop, all of this responsibility might lay on your shoulders as the project lead.
Plan for Transition
If you are involved in a small, intimate software-development group and your team is going to handle the ongoing maintenance of the project, and all of the "intellectual capital" that went into the building of the project is contained within your group, you are probably in a good position to relax a little and use the time in post-production and support to do the documentation and training materials—or actually even perform the training yourselves.
In an organization in which there is more of a multi-team, enterprise-level approach to IT management and software development, it becomes harder to push this off to the end of the project; invariably, at the end of a project, the team that developed the application is not the team that wants to do the maintenance of it. Chances are that they want to hand-off the operations and maintenance to another designated team, and then pick up the next shiny project to work on and start the process all over again.
Sometimes, this transition is done without forethought and usually leaves the maintenance team to which the project was handed off in a lurch. This might translate into an interruption in the ability of the Operation and Maintenance team to pick up the responsibility properly for the ongoing health of the project, which affects the end users' ability to perform their tasks efficiently. I have seen this happen on projects in the past, and it usually means that engineers who have moved onto new projects have to be called back to the maintenance team for knowledge transfer or emergency surgery of the application, depending on the level of criticality of the failure. Either way, dumping a project from development to maintenance without the right level of transition preparedness is a sure recipe for the project to fail in the organization.
If you are a software architect in a consulting organization in which you are a "hired gun" who comes in and tactically does a specific project, the implementation of that up-front perspective on driving attention to the issues of organizational readiness must start the first day that you are on the job. If you do not start it immediately, it will never happen, and the transition of the project from development to implementation has all the risks of an egg-toss game at the company picnic: A lot of people will wind up messy and mad, because they did not have the skills to play the game.
Specifically, on software projects, businesses are looking for ways in which to cut costs. One of those ways that is popular these days is to have one team develop or integrate a solution and, after it is complete, to pass it off to an outsourcing firm for operation and maintenance. Chances are that there is little to no time for the outsourcing firm to do knowledge transfer or infrastructure preparation, and there will be performance impacts to the transition of the application from development to production. This "dip" in the hand-off of the project from one team to another—no matter how remote or culturally different they are from one other—can be mitigated, to some degree, by thinking ahead during project-design phases.
As you can see, implementing organizational-readiness activities in your project plan is above and beyond the technical process of software architecture. The good thing is that it is not a hard process to add into the mix of your development process. Put forth the effort, and make your project visible and accessible to your organization. Asking for and getting feedback all along the project timeline is critical to both the success of your project and the readiness of your organization to accept the chaos that your solution will cause.
When people have a say in what their tools and processes are, they will be more willing to make changes from their current ways of doing things to the new ways that your solution will introduce into the organization. Increasing your organization's readiness to change will really make your project successful.
- Can you visualize the end of the project? Visualize that you will be taking a 3-week cruise at the end of the project and that no one can reach you. What are the things that must be in place and ready to go at the end of the project, so that when you are on your cruise the Coast Guard is not called out to pull you off the boat and bring you back to the office to fix the annoying little issues that you forgot? (Hint: Start thinking of this before you go into development—not when you get close to acceptance test.)
- Doing the project technically correct is only part of the project. The other part of the project should be the preparation of the IT team that will be responsible for ongoing maintenance and operation. This can be accomplished in several ways:
- Involve QA in the project—if you happen to have those roles available to you—and make it part of their responsibility in the project to involve the roles that are identified as potential impact points for when your project transitions over to production.
- Involve some of the transition team in the latter parts of the project, such as in the area of system-integration test, and let them be the testers who run the test scripts to validate the operation of the project to requirements. This will give them a chance to experience the application in operation and make contact with the developers of the application who are responsible for specific areas of the application. This will build a relationship between the tester/maintenance/operations person and the developer, should there be any need to contact the developer for advice or assistance after the application is in production. This process also allows for an "organic opportunity" for the maintenance and operations roles to gather knowledge transfer before the application goes to production. They have seen the bugs, they know how it operates, and they know the work-arounds. What better training can you provide the transition team than to have them participate in the project itself?
- Have you planned for training of the solution after it has gone into production? Who is going to be doing the training, and for how long? What materials must be produced or resources put in place to facilitate the training?
- Have you planned for the preparation of the support team that will be taking end-user support calls on the application? Are they well exposed to your solution? Have they added to the support database "knowledge-base" questions and answers that might have been identified from the testing phases of the application-development process? Have you created any "self-support" pages (intranet Web sites, WIKI pages, FAQs, quick-reference guides, cheat sheets, and so on) that users can search in order to ease transition, without them having to rely on the helpdesk for everything after your solution is in production?
- Did you get user commitments and input throughout the development of your solution, to make sure that issues of transition or change at the users' level were properly addressed?
- During the development of the project, did you have biweekly impact reviews in which folks who know about the project and are key users, transition staff, operations, maintenance, or just plain nosy folks have a chance to ask questions and put issues to be aware of on the table?
About the author
Michael C. Martin is an Executive Consultant with IBM Global Services in Atlanta, GA. He has worked in the IT industry for over 25 years for IBM, Apple, GE, Attachmate, and DCA in roles of Developer, Technical Support, Software Architect, Department Manager, Director of Software Development, and Consultant.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.