Design Skills: The Practice of Design
Miriam Grace and Sandra Y. Jeffcoat
Summary: To meet the challenges placed on us by both the customer and our IT leadership, we must understand the whole system of interconnected elements that participate in, affect, and influence the design process. Design is about understanding "the whole system." (3 printed pages)
Our customer says, "I want our new system to have a response time of no more than two seconds!"
Our IT Director says, "We must cut cost! All new development efforts must fit within our existing environment, using existing tools."
We have all faced these challenges many times, and we are used to design challenges that have both stringent customer requirements and built-in Information Technology (IT) constraints that are due to existing environment or technology realities. So, what do you do in such cases? You dig deep and become very creative. You pull out all of your design skills. What does that mean? If you are like us, you have a solid foundation in design methodology, have strong technical skills, and well-honed people skills like negotiating and communicating. So, it means that you put them all together and get to work!
As architects, we have found that to meet the challenges placed on us by both the customer and our IT leadership, we must understand the whole system of interconnected elements that participate in, affect, and influence the design process. The scope of a software architect's world is awesome, as the breadth of experience that is documented on this site demonstrates. "Today's large-scale software systems are among the most complex structures ever built by humans, containing millions of lines of code, thousands of database tables, and hundreds of components, all running dozens of computers" [Rozanski & Woods, 2005]. For us, design is the discipline that allows us to tackle the complexity of building a system in the highly networked and complex technical and social environments that exist in today's global corporations.
Collaborate to Understand the Business
Design methods direct us first to work as collaborative partners with our customers, to understand their vision and the strategy for their business operations. We approach our work as "service providers" and operate in a service relationship with our customers. Where possible, we participate fully in business-process development or Joint Application Development (JAD) sessions in which customers document their ways of doing business from a process perspective. Together, we look for ways to streamline and automate their work. We see our customer's business-process architecture as key to a rich requirements definition. The clearer customers can describe their value streams and subprocesses, the firmer the foundation that we have for our system-design work.
Evaluate the Ecosystem
As soon as we understand our customer's business requirements, we look at the whole system of which our target system is a part. We study the people, processes, structures, and technologies that compose the "supra-system" in which our system will operate. We understand the existing interfaces between systems, the technology interactions, the interrelationships between existing business processes, and the established habits of interaction between existing organizational and other structural components. This sets the context for our system-design work, a knowledge base traditionally called a "context diagram." This is the architect's rendering of the proposed system and its interfaces to external systems or sources of data. It is a valuable communication tool that is used to establish high-level systems architecture, verify assumptions about system interfaces, and assist in future project planning by affected systems.
Determine the Data Structure
Meanwhile, the detailed work can get underway. At this point, we have a conceptual data model that is constructed concurrently with the customer's business-process architecture. Next, we determine the data structures for an initial database design, including table definitions, data elements, and table indexes, as well as all of the components that protect the integrity of the data.
Understand the UI
The data-structure design process requires us to be very familiar with the database-management system that is in use. In conjunction with data-structure design, we work directly with our systems analysts and customers to design specific system-interface screens, reports, and programs. In this important phase of system design, we create the environment in which users will operate and interact with the system. If the user interface is not well designed, all of the best technology in the world will not be able to make people use the system. It is at this point that all of the hours that were spent with the customers in their business-process design sessions pay off and deep knowledge of the data structures is essential.
Include the Interfaces
After they have been created, the system interfaces allow the input of data, transformation of the data, and output of the transformed data to perform various business functions. The way in which we design this part of the system has to take into account specific federal regulations, international standards, or information-control and protection safeguards. Specific existing technologies, or existing infrastructure components, also have to be considered in our design. For example, the hardware that is being used, the network topology, specific operating systems, and the like must be considered, because such components are constraints on our design.
Review the Design
When we finally have screen mock-ups and an understanding of how best to configure the system hardware and software to meet customer requirements, we create another graphical depiction of the system. This time, we break the system into logical components and transform them into a graphical presentation that provides the users with a view of the system prior to the expensive build process.
We have found the old carpenter's saying "measure twice, cut once" to be very applicable to system-design work. As much as possible, we show the customer and our colleagues our ideas on paper before we ever begin coding a system. Sometimes, we even build a quick prototype when we want to demonstrate an idea, to ensure that we are fulfilling the customer's vision before we go to the expense of building the final system. We always remember that we operate in a service relationship, and the last thing that we want is to design and build something that the customer cannot use. Also, we have found that our customers appreciate the opportunity to view and get a feel for what is going to be delivered. They appreciate the opportunity to make changes and have a voice in determining what their system will look like. This also ensures that we are partners in the process all the way through and that there are no surprises at the end.
By involving users in the design process and directing the technical team that is working with us, we have found that the competencies that are required to perform the cross-disciplinary role of a software architect are varied; they run the gamut from the "hard" science of systems engineering to the "soft" skills of creating effective human relationships. Although not generally thought of as design skills, strong collaboration skills are needed for situations of extreme pressure to enable effective execution of other, more traditional design capabilities. Presentation skills are also critical and have often been the determining factor between making or breaking a project. The ability to present technical facts in a language that non-technical people can understand has been crucial to obtaining buy-in for design proposals, as well as for business-case analyses and resource funding. Negotiation is a design skill that we often use when we try to negotiate a design that might not be exactly what our customer is hoping for, but that is the best fit, given the available technology, budget, and constraints.
We have been decision-makers and mediators when resolving conflicts and issues among team members and other stakeholders. The ability to make decisions and demonstrate unwavering self-confidence has come in handy when we have been put in positions in which we have had to make unpopular decisions. Perhaps the most difficult skill of the "soft skills" that we have needed during design is the ability to navigate through organizational politics, to get the system built correctly and in a timely manner.
Lastly, we have had to be strong leaders and mentors. Without the ability to present ideas, collaborate and negotiate, deal with office politics, and foster learning, an architect cannot be successful.
An architectural view is a description of one aspect of a system's architecture. Creating multiple views of an architecture allows an architect to understand, define, and communicate a system design in a partitioned fashion, so that different audiences can comprehend the architect's intentions in the context of their work and in their own language. Viewpoints are "templates" that architects use to guide them in the development of the different views. "Viewpoints contain proven architectural knowledge to guide the creation of an architecture, described in a particular set of views (each view being the result of applying the guidance in a particular viewpoint)" [Rozanski & Woods, 2005].
[McGovern et al., 2004] McGovern, James, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo. A Practical Guide to Enterprise Architecture. Upper Saddle River, NJ: Prentice Hall PTR, 2004.
[Rozanski & Woods, 2005] Rozanski, Nick, and Eóin Woods. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Boston, MA: Addison-Wesley Professional, 2005.
About the authors
Miriam Grace is an Enterprise Systems Architect and a member of the Boeing Technical Excellence Fellowship. She has over 20 years' experience as a computing systems architect, with a specialty in business-process management systems. Miriam is a published author, holds a Master's degree in Systems Design, and is a Ph.D. Candidate in Leadership. She designed a learning system that has provided a curriculum of foundational skills for software architects at Boeing.
Sandra Y. Jeffcoat is a member of Boeing's Technical Excellence Program, a 2005 National Women of Color in Technology and 2007 National Society of Black Engineers (NSBE) Golden Torch awards winner, and a Ph.D. candidate for the Antioch University Leadership and Change Program. Sandra has more than 28 years of technical experience for such companies as the Boeing Company, Eastman Kodak, NCR, Mead Paper Corporation, AT&T, and various government agencies.
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.