Products and processes are two of the most vital components of a successful business. Useful, relevant, or innovative products are important for attracting and keeping customers. Efficient and effective processes are crucial to making the customer experience enjoyable and worthwhile. Product and process should therefore be included as key components in any business architecture.
But, too often, product and process are not given the architectural priority they deserve. While physical products such as cars or planes are highly engineered, enterprise architects tend to overlook the architecture of information-based products and view them instead as the domain of business managers. (Note that physical products, such as the engineering of cars or computers, are more likely to be architected than information or digital products, such as financial or insurance components.) Process, on the other hand, is more likely than product to be mentioned in the business architecture yet is often regarded as too intricate to warrant an architectural approach, leaving its detailed examination to business analysts. As a result, architects often bypass product and process in favor of strategy and capability.
In addition, the architectural interrelationships and dependencies between product and process are not fully recognized. So not only do product and process receive less attention than they warrant, but we fail to architect products and processes together. Consequently, organizations frequently reengineer processes only to find that introducing a new product or changing an existing product requires further significant process alteration. Or, we see new product features being introduced with widespread disruption to services and processes.
Whenever an organization requires change, certain people must be involved. These people are on the “critical path” for change. Yet, as more and more people collaborate on that critical path, change becomes more complicated. When those people are in high demand and are difficult to pin down, it takes longer and adds administrative overhead. If those people are in short supply or are highly skilled, it results in resource issues and spiraling costs. So it makes sense to reduce the number of people on the critical path, reduce their degree of involvement, and minimize the need for specialized skills, knowledge, or experience.
Products and processes are probably the most demanding components in enterprise architecture when it comes to involvement of large numbers of decision makers, designers, analysts, and architects who are highly experienced, knowledgeable, and skilled. EA can, and should, reduce pressure on the critical path for change. By architecting product and process at the same time, we can reduce the number of people blocking the critical path — and significantly improve agility. Think of an important architectural challenge you face today: how many people are on the critical path?
For more on the main architectural constructs that support product and process, see my Cutter Consortium Executive Report “Architectural Constructs for Agile Products and Processes“.