When we’re part of a team creating software for the enterprise – an internally focused, IT initiative, we usually don’t think about product managers. Business analysts, systems analysts, and architects (of all varieties) are all commonplace. But not product managers. Product managers bring a perspective and a strategic focus that can influence the success of an IT enterprise initiative.
Enterprise Reality
Folks who have worked with large IT departments will know what enterprise projects are. These are projects that are strategic to the company, usually map to one or more initiatives, and always seem to affect multiple “software products” within the enterprise and multiple organizations. Each “product” within this corporate software ecosystem is “owned” by someone. That ownership manifests in different ways with different companies.
As an aside – while living in this world at the moment, it didn’t occur to me to write about it until I read this article, by David Margulius, asking people to write about this topic.
A common way that “ownership” manifests for a “product” within an IT infrastructure is that someone runs the product as a cost-center. That person is responsible for development of new capabilities (as an order taker, in David’s terms), and all implementation and testing of the product. Sometimes, the owner is also responsible for deployment of the product, sometimes not.
To the product managers out there, this screams out “use a product roadmap” to manage your product. And the product team should manage a product roadmap. Business analysts are comfortable here too – eliciting the needs of the business, prioritizing, and coordinating value with cost and practicality to develop a schedule of “what gets delivered and when.”
Generally, all of the product management and business analysis skills associated with “going deep” in the creation of a software product will apply here, to this team.
Where this team will likely not be able to make progress is in recognizing that it is part of an ecosystem of inter-operating applications. What is required is a broad view.
Business Architecture
Business architecture is one of those definition-overloaded labels that means different things to different people. To us, business architects should focus on how the business is run – end to end – not on the tools used to run it. This is the broad view of the enterprise. Your company might have business architects reporting within the business, and you may also have business architects that are part of IT.
IT business architects should not be owning the processes – the business should own the process. But IT business architects should own the communication of those business needs (expressed as processes) with the IT teams responsible for implementation.
Broad
Business processes in an enterprise span multiple applications. Each application plays a role within that ecosystem of connected applications to enable those processes. To make good decisions in this environment requires both a broad and a deep view of the enterprise.
Business architects should take a broad view of the enterprise. Those architects within the business should focus on the strategic initiatives of the company. They answer questions like “how can the company do business to achieve particular goals?” Business architects within IT should mirror this broad view, answering questions like “how will IT support those processes to enable the business to achieve its goals?”
Architectural work (the development on a grand-scale kind) is the design process that identifies what applications need to exist, and how they need to inter-operate to enable these business processes. These architects (technical architects, enterprise architects, solution architects – there are many titles) are doing “implementation” from a requirements point of view.
However, this “implementation” is at such a high level, that there is still much work to do. The result of this architecture is a broad view of how IT will support the business, with a collection of applications (or services, or whatever).
Deep
Now we get back to the “traditional” requirements work. An application has a set of requirements, which are prioritized, and which drive a product road map and implementation plan. This is a long term, deep, product-centric view of the world. The product manager focuses on the users and their goals, as well as the business stakeholders and their goals. These are combined to define the road map for the application. Much like any other product development.
Broad and Deep
However, these applications live in the context defined by the business architects and the enterprise architects. When enterprise architects design a solution of applications, they are effectively defining the scope of each application (within their design). For example, an online portal may be responsible for taking orders, while a fulfillment system is responsible for filling the orders, and an accounts-receivable system is responsible for collecting the funds to pay for those orders. The architects are defining scope when they choose these boundaries.
The business architects and the enterprise architects work together to map the business processes onto the enterprise architecture. Since the business is providing requirements as inputs into the processes, this mapping defines the requirements for the applications.
This presents a natural transition from the broad view (what must IT do, to support the business) into the deep view (what must my application do, as a part of what IT does).
Conclusion
This may present organizational challenges, depending on how IT teams are staffed and budgets are managed – but it also provides a framework and approach that allows for validation of requirements, communication with the business, and clear responsibilities for the people who actually “make it happen.”
