Software Engineering, Project Management, and Effectiveness
Your company's foundation for execution will make or break your survival in the market for the long haul. How can you incrementally build and shape the foundation, while executing projects? How do you connect and align IT with your business vision, while shaping your foundation for execution?
You can use three linking mechanisms to build and shape your company's foundation.
In the book, Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Jeanne W. Ross, Peter Weill, and David C. Robertson write about three linking mechanisms that help you build and shape the company's foundation.
Linking mechanisms are the key to building and shaping your company’s foundation for execution. You can incrementally shape the foundation as you drive projects. You can also inform your company’s foundation as you learn from your projects. Ross, Weill, and Robertson write:
“Good linking mechanisms ensure that projects incrementally build the company's foundation and that the design of the company's foundation (it's operating model and enterprise architecture) is informed by projects.”
According to Ross, Weill, and Robertson, the three linking mechanisms are:
Architecture linkage connects projects to IT governance choices about architecture. Ross, Weill, and Robertson write:
“Architecture linkage establishes and updates standards, reviews projects for compliance, and approves exceptions. Architecture linkage connects the IT governance decisions about architecture with project design decisions. For example, a company working to increase integration may have a mechanism for insisting that a supply chain project -- rather than focus narrowly on its own data needs -- restructure an inventory database so that it facilitates anticipated future uses of the inventory data. Companies may fulfill architecture linkage with one mechanism, such as an architecture review board. More commonly, firms employ multiple mechanisms, ranging from architect training programs to architecture exception processes.”
Business linkage links projects to business goals. Ross, Weill, and Robertson write:
“Similarly, business linkage ensure that business goals are translated effectively into project goals. Business linkage coordinates projects, connects them to larger transformation efforts, and focuses projects on attacking specific problems in the best possible way. For example, a key linking mechanism for companies pursuing companywide standardized processes is the use of process owners with primary responsibility for designing and updated processes. Business linkage also includes incentive programs to guide behavior as new projects demand new ways of thinking.”
Alignment linkage connects business and IT relationships. Ross, Weill, and Robertson write:
“Alignment linkage mechanisms ensure ongoing communication and negotiation between IT and business concerns. Business-IT relationship managers or business unit CIOs are typically a critical linkage for translating back and forth between business goals and IT constraints. Other mechanisms in this category include a project management office, training and certification of project managers, and metrics for assessing projects.”
It’s a maturity thin. The more you practice the linking mechanisms, the more it becomes an organizational habit. Ross, Weill, and Robertson write:
“Earlier we noted that a company's management practices evolve through the stages of architectural maturity. Many of these evolving practices are linking mechanisms. As they are implemented and improved, they contribute to increasing sophistication of the IT engagement model. Over time, linking mechanisms can become increasingly embedded in IT governance and project management processes so that linking becomes an organizational habit.”
How do you balance giving teams flexibility to innovate and architectures being reviewed by a board? On the opposite side, I do see daily the problems of having no integration, or board, and people just making the data model fit their one project's needs and this causes rework or work-arounds down the road for other teams.
You've asked a great question -- It's tough to give a robust answer because it's very contextual, but I'll give you some food for thought.
How to balance flexibility + control is art + science. The most common problem is to over-engineer the science part and break the people through complexity and overhead, and stifle the art.
On patterns & practices, we drove tech governance through a variety of mechanisms, while putting a premium on innovation and continuous learning. We focused on architecture principles + periodic reviews. Early in the cycle, we would lock on some common guidelines, and do an early review of the architecture to catch things like integration plays, high-risk decisions, and redundancies. Through Agile process, we allowed for learning, re-factoring, and do-overs from one iteration to the next.
Investing in the test team was a great way to spread governance, and to quantify the impact. Swapping people around also helped spread tribal knowledge that would have been very difficult to "govern" our way into through docs, or policies.
Here are a few checks to balance and guide governance:
* Do you know and agree to the outcomes you want to drive?
* Did the right people review the right things?
* Is there a way to treat incubation differently?
* Can you batch governance into meaningful milestones rather than death by a 1,000 paper cuts on a daily-basis?
* Does your process catch the integration opportunities, enforce standardization where it counts, de-risk the high-risk stuff, and reduce redundancies?
* Can you process itself learn and improve, at a rapid pace and light-weight way?