An equipment distributor acquires a professional training business and expects to sell a combined customer offering. The first technology proposal is to merge the customer systems. The acquisition thesis, however, depends on questions that a shared database cannot answer: which training fits which equipment, who owns the combined offer, and what each team may promise.
This hypothetical acquisition shows why a CIO’s contribution can extend into business architecture. The role is to make the relationship between strategy, operating capabilities, information, and technology explicit enough for the executive team to choose a workable design. It does not give the CIO unilateral authority over commercial policy or professional judgment.
The argument is a direction for the role, not a prediction that every company will adopt the same title or structure. A CIO who can expose the operating assumptions inside a technology request is better positioned to help the business change coherently. The useful deliverable is a decision-ready view of how the business will work, rather than a larger diagram of its applications.
Translate the strategic intention into a capability question
Ask what the business must be able to do for the strategy to succeed. Cross-selling might require identifying eligible customers, designing a compatible offer, preparing a supported quotation, coordinating delivery, and resolving a problem across the combined service.
Do not assume those capabilities already exist because each acquired business performs part of the work independently. A training provider can deliver its courses and an equipment supplier can deliver its products while neither can own the combined customer outcome.
Identify the decisions that define the capability. Which products and courses may be offered together? Who confirms suitability? Which entity contracts with the customer? Which team handles questions after delivery? The responsible commercial, operational, and professional owners must settle those matters.
The CIO can structure the inquiry and show its implications. A decision about the contracting model affects records, permissions, workflow, and reporting. Making that connection early helps prevent software configuration from becoming the accidental source of business policy.
A hypothetical acquisition blueprint
Imagine a distributor of industrial measurement equipment acquiring a training provider serving adult professional users. Management wants customers to obtain equipment and an appropriate training package through a coordinated sales process. No particular qualification or regulatory status is assumed in this example.
The initial systems inventory shows customer records, product catalogs, course schedules, and separate support tools. A platform-first review proposes one customer-management application and a shared portal. The business-architecture review asks whether those changes are sufficient for the intended offer.
It finds that equipment compatibility and training suitability are not represented by a common rule. Some courses apply to particular models or configurations, and specialist owners must validate the mapping. A merged catalog without that decision could make an unsuitable package easier to sell.
The customer relationships also differ. The equipment buyer may be a company purchasing function, while training attendance involves individual professional participants and a sponsoring department. Those records need appropriate relationships and access, not an assumption that every contact belongs in one unrestricted view.
The executive team therefore defines a bounded first offering: selected equipment families with approved training mappings, an accountable commercial owner, a clear delivery handoff, and a supported route for exceptions. The CIO maps the information and interfaces required to implement that design and compares viable technology options.
The first technology investment may be a controlled offer catalog and a coordinated workflow rather than immediate replacement of both customer systems. Later consolidation remains possible if it supports the operating model and its economics. The architecture makes that choice visible without prescribing a product in advance.
Use several connected views of the business
A capability view describes what the enterprise must be able to do without immediately naming the application. A value-flow view shows how a customer outcome is produced across those capabilities. An information view explains the business objects and relationships needed to make the decisions.
A responsibility view identifies who sets policy, performs the work, accepts the result, and maintains the capability. A technology view then shows how systems and interfaces support the agreed design. The views should answer related questions rather than become separate documentation exercises.
GAO’s 2010 enterprise-architecture guidance describes current and target operational and technology environments and a transition roadmap. It is a flexible public-sector framework, not a universal private-company checklist, but it supports examining business and technology change together. GAO-10-846G, Enterprise Architecture Management, 2010
Keep the views proportionate to the decision. The acquisition team does not need a complete model of every business activity before testing one combined offer. It does need enough detail to expose the conditions that make that offer deliverable and governable.
Make tradeoffs visible before selecting the platform
Compare alternatives at the operating-model level. The businesses might retain separate contracting and delivery with a referral relationship, create a coordinated package, or integrate more deeply. Each choice implies different data, responsibility, and customer-experience requirements.
Evaluate what must be common and what may remain separate. Shared product identity and suitability rules may be essential, while local scheduling practices may vary legitimately. A single platform can support variation, and multiple platforms can sometimes support a coherent capability if the contracts between them are dependable.
Include the transition burden. A technically attractive target can consume scarce business expertise or disrupt a working service. The CIO should show the path from current operation to the proposed model, including temporary arrangements and the conditions for retiring them.
Do not use architecture as a way to avoid commercial choices. A model can expose conflicting objectives, but the executive team must decide the priority. The CIO’s value includes making the consequence understandable, not pretending that a technical design removes the tradeoff.
Build evidence into the architecture work
Test the proposed capability with representative cases. For the acquisition, include an eligible package, an uncertain suitability question, a customer with several sponsoring departments, and a delivery exception that crosses the two businesses.
Ask the receiving teams to explain what they would do and what information they need. If the answer depends on an informal relationship or an assumption that no owner accepts, the architecture is not yet complete enough for implementation.
Use prototypes to examine uncertain interactions. A small controlled offer workflow can reveal whether the mapping, responsibility, and information design are usable. It does not establish full-scale reliability or the economics of replacing all supporting systems.
Measure the architecture by the decisions it improves. Useful results include avoiding an unnecessary replacement, exposing a missing operating responsibility, or identifying a dependency before a large commitment. Diagram count is not a meaningful outcome on its own.
Mark unresolved assumptions directly in the decision view. A proposed suitability rule, an unconfirmed data-sharing arrangement, and a demonstrated interface should not appear equally established. Give each material uncertainty an owner and a test or decision point, so the picture does not acquire authority simply because it is neatly presented.
Keep technical quality within the CIO’s responsibility as the role broadens. Reliability, security, maintainability, and appropriate cost remain essential to the business capability. Becoming more involved in operating design should improve those connections, not turn technology leadership into strategy discussion detached from the systems the company depends on.
Share the architectural responsibility
Business architecture should be developed with the people who own the business. The CIO may lead the connection between capabilities and technology, while commercial, finance, operations, security, and other specialists retain their responsibilities.
Create a decision forum that uses the connected views to resolve material choices. Keep routine design authority delegated to appropriate owners. If every question waits for an enterprise committee, architecture can become a bottleneck rather than a source of clarity.
Develop business literacy within technology teams and technical literacy among business leaders. Analysts and engineers need to understand why a customer relationship or suitability rule matters. Business leaders need to understand why inconsistent identity or an unreliable interface can undermine the intended offer.
Preserve the rationale as the organization changes. A successor should be able to understand why the first offering was bounded and what evidence would justify expansion. Without that history, a later project may remove a deliberate constraint while believing it is simplifying the system.
Keep the blueprint connected to live operation
After launch, compare the intended capability with actual outcomes. Are the combined offers appropriate? Do customer questions reach the right owner? Are staff maintaining the agreed mappings? Those observations can change the architecture’s assumptions.
Treat new requirements as changes to the operating model where necessary. Adding another equipment family may be a simple catalog update or may require new training expertise, information, and authority. The architecture should help distinguish those cases.
Maintain links to investment and service ownership. If a capability depends on information no team funds or on a partner no one manages, the target design will decay. Ongoing stewardship belongs beside the initial implementation plan.
The distributor’s CIO can now discuss the acquisition thesis in concrete terms: the capability required, the decisions still open, the information that must be governed, and the options for delivering it. That is the business-architect contribution. It prepares technology leadership to shape enterprise change while keeping the business’s choices and accountability where they belong.
