Article

From Business Need to Technology Solution

Author: Agus Budi Harto, 2026-03-07 14:39:41


How Non-IT Organizations Bridge the Gap Between Strategy and Software

Introduction

In today's digitally driven economy, businesses across every sector — from manufacturing and healthcare to logistics and financial services — are increasingly reliant on technology to remain competitive, compliant, and efficient. Yet for most organizations, technology is not their primary business. A hospital's mission is to heal patients; a bank's purpose is to manage money; a retailer's goal is to move goods. Information technology, in these contexts, exists to serve the business — not the other way around.

This creates a fundamental challenge: how does an organization translate what the business needs — often expressed in operational, financial, or strategic language — into a working technology solution? How do the people who run operations communicate effectively with those who build software? And who, exactly, are the people involved in making that translation happen?

This article explores the frameworks, methods, and organizational structures that corporations commonly deploy to bridge the gap between business requirements and IT solutions. Whether you are a business leader seeking to understand your internal IT department's processes, or an IT professional looking to communicate more effectively with your stakeholders, this guide offers a comprehensive and practical perspective.

Why the Translation Problem Exists

The gap between business needs and technology solutions is not simply a language problem, though that is certainly part of it. It is a gap in perspective, priority, and abstraction. A business manager sees a problem in terms of outcomes: sales are falling, customers are complaining, reports take too long to produce. An IT developer sees a problem in terms of systems: databases, APIs, interfaces, and logic rules.

Between these two worlds lies a vast middle ground where most IT projects either succeed or fail. Research consistently shows that the majority of IT project failures — whether in cost overrun, missed deadlines, or outright abandonment — stem not from technical inadequacy but from poorly defined or misunderstood requirements. The technology itself is rarely the problem. The problem is building the wrong thing, or building the right thing for the wrong reason.

This is why structured approaches to requirements translation have become indispensable in modern organizations. Without a deliberate method, critical information is lost in each handover, assumptions are made without validation, and the final system often solves a problem that has already evolved or was never precisely defined in the first place.

Frameworks and Methods for Requirements Translation

Over the decades, both academic researchers and industry practitioners have developed a rich body of frameworks specifically designed to address this translation challenge. Each framework approaches the problem from a slightly different angle, and in practice, most organizations adopt a combination of methods tailored to their size, culture, and maturity level.

Business Analysis Body of Knowledge (BABOK)

The most widely recognized standard for requirements translation comes from the International Institute of Business Analysis (IIBA). Its cornerstone publication, the Business Analysis Body of Knowledge — known as the BABOK Guide — defines the discipline of business analysis and provides a comprehensive set of techniques for eliciting, documenting, and validating requirements.

BABOK introduces the concept of requirements at multiple levels: business requirements (the high-level goals of the organization), stakeholder requirements (what specific groups need), solution requirements (what the system must do), and transition requirements (what is needed to move from the current to the future state). This tiered model is extremely useful for non-IT organizations because it ensures that IT solutions are always traceable back to a genuine business goal.

Practical BABOK techniques include structured interviews with stakeholders, facilitated workshops, business process modeling, use case development, and prototyping. Each technique is designed to surface knowledge that business users often hold implicitly — knowledge they may not even realize they possess until the right question is asked.

TOGAF and the Architecture Development Method

The Open Group Architecture Framework, or TOGAF, offers a more strategic and architectural view of the translation process. Its Architecture Development Method (ADM) is a step-by-step approach for developing an enterprise architecture — essentially a blueprint that maps business goals, processes, and information to technology systems and infrastructure.

What makes TOGAF particularly valuable for large non-IT corporations is its explicit focus on maintaining alignment between business strategy and technology investment. The ADM begins with the business architecture — defining what the organization does and what it needs — before progressing to information systems architecture and finally to the underlying technology. This ensures that IT solutions are always grounded in business context.

TOGAF is commonly used in sectors such as government, banking, and telecommunications, where the scale and complexity of operations require a disciplined architectural governance approach.

Zachman Framework

The Zachman Framework, developed by John A. Zachman in the 1980s and refined over subsequent decades, provides a structured schema for understanding and documenting complex organizations and their systems. It organizes enterprise architecture across two dimensions: the communication interrogatives (What, How, Where, Who, When, and Why) and the stakeholder perspectives (from executive planner to technology implementer).

For non-IT organizations, the Zachman Framework is particularly useful because it makes explicit the fact that different stakeholders have different but equally valid perspectives on the same system. A CEO's view of a customer relationship management system is fundamentally different from that of a database administrator — and both views are necessary for a complete solution.

Scaled Agile Framework (SAFe) and Agile Methods

In environments where speed and adaptability are paramount, Agile-based methods have become the dominant approach to requirements translation. The Scaled Agile Framework (SAFe) is specifically designed for large organizations that need to apply Agile principles at scale, coordinating multiple teams working on related solutions.

In SAFe and related frameworks, business requirements are expressed as Epics at the strategic level, broken into Features at the program level, and further decomposed into User Stories at the team level. Each user story follows a structured format — 'As a [user], I want [capability] so that [benefit]' — that keeps the focus firmly on the business value being delivered. This hierarchical decomposition is a powerful translation mechanism because it maintains the connection between strategic intent and day-to-day development work throughout the project lifecycle.

Business Capability Mapping

A more pragmatic and accessible approach, business capability mapping involves defining what a business does — its capabilities — and then assessing how well existing systems support each capability. Gaps between current capability and desired capability become the basis for IT investment decisions.

This method is particularly effective in industries undergoing digital transformation, such as retail, logistics, and healthcare, because it grounds technology decisions in operational realities rather than abstract technical visions. A capability map makes it easy for business leaders to understand and endorse IT priorities, because the conversation is conducted in terms of business outcomes rather than technical specifications.

Industries Beyond IT: Real-World Application

Manufacturing and Industrial Sectors

In manufacturing organizations, the translation of business requirements into IT solutions often revolves around production efficiency, supply chain visibility, and quality management. Business requirements in this context might include reducing machine downtime, improving inventory accuracy, or accelerating the production planning cycle. These needs translate into systems such as Enterprise Resource Planning (ERP) platforms, Manufacturing Execution Systems (MES), and Industrial Internet of Things (IIoT) solutions.

The challenge in manufacturing is that many of the most critical requirements are held by shop floor operators and engineers who are not accustomed to articulating their needs in formal documentation. Business analysts in this industry must be especially skilled at process observation, contextual inquiry, and translating tacit knowledge into explicit requirements.

Healthcare and Life Sciences

Few industries face a more complex requirements translation challenge than healthcare. Clinical requirements must be balanced against regulatory compliance, patient safety, data privacy, and operational efficiency. A requirement as seemingly simple as 'the nurse needs to see the patient's medication history' unfolds into a complex web of system integrations, access control rules, audit trail requirements, and interface design considerations.

Healthcare organizations commonly work with clinical informatics specialists who bridge the gap between clinical staff and IT teams. These specialists understand both the clinical workflow and the technical landscape, making them invaluable translators in a domain where errors can have life-or-death consequences.

Financial Services and Banking

In financial services, business requirements are heavily shaped by regulatory mandates, risk management policies, and the need for real-time transaction processing at massive scale. A requirement to 'comply with the new reporting regulation' must be translated into specific data capture rules, calculation logic, report formats, and audit trails — all of which must be validated against legal interpretations before development begins.

Banks and insurance companies typically employ large teams of business analysts and solution architects who specialize in regulatory change management. These professionals maintain detailed knowledge of both the business domain and the technical systems, enabling them to assess the impact of regulatory changes and design targeted IT solutions.

Retail and E-Commerce

In retail, business requirements are driven by customer experience, inventory management, pricing agility, and omnichannel integration. A retailer might express a need as 'customers should be able to return online purchases in any store' — a requirement that, when unpacked, involves order management systems, inventory systems, point-of-sale systems, and customer identity management, all of which must exchange data in real time.

The pace of change in retail means that requirements translation must be fast and iterative. Agile methods, particularly the use of product owners who are deeply embedded in the business, have become standard practice in the industry.

Logistics and Supply Chain

Logistics organizations demand high degrees of operational precision and real-time visibility. Business requirements in this sector often involve tracking shipments, optimizing routes, managing warehouse operations, and coordinating across multiple third-party partners. The translation challenge is compounded by the need to integrate with external systems — carriers, customs authorities, and trading partners — each with their own data formats and communication protocols.

The Parties Involved: From Corporate Director to IT Engineer

One of the most important and often underappreciated aspects of requirements translation is the number and variety of people involved. In a non-IT organization with an internal IT department, a single IT initiative — whether developing a new application or significantly modifying an existing one — will typically engage between six and twelve distinct roles, spanning both the business and technology sides of the organization.

The Business Side

At the executive level, the Business Sponsor or Business Owner — typically a C-Suite executive, Vice President, or Senior Director — provides strategic direction, authorizes the budget, and holds ultimate accountability for the outcome. The sponsor's involvement is critical at the beginning and end of a project, but they are rarely involved in the day-to-day details of requirements definition.

Below the executive sponsor sits the Business Manager or Department Head, who owns the business problem being solved. This person defines what success looks like from the operational perspective, represents the business unit in steering committee discussions, and is responsible for ensuring that the delivered solution is adopted by their team. In many organizations, this role is the most important voice in shaping the requirements.

Subject Matter Experts (SMEs) are the operational staff who possess deep knowledge of the current process and its pain points. They are the primary source of detailed requirements and are indispensable partners for business analysts during the elicitation phase. End Users — the people who will actually use the delivered system on a daily basis — provide a different but equally important perspective, focused on usability, workflow fit, and practical efficiency.

The Bridge Roles

The most critical actors in the requirements translation process are those who occupy the space between the business and technology worlds. The Business Analyst (BA) is universally recognized as the primary translator. A skilled BA elicits requirements through structured interviews, workshops, and process observation; documents those requirements in formats that both business stakeholders and IT developers can understand; and validates the documented requirements against business intent before development begins.

The Project Manager (PM) ensures that the translation process is governed effectively — managing scope, timeline, budget, risks, and stakeholder communication across both sides of the organizational divide. Without strong project management, even well-defined requirements can fail to result in a successful delivery.

In Agile environments, the Product Owner (PO) plays a role analogous to the BA and PM combined, maintaining the product backlog, prioritizing features based on business value, and serving as the primary decision-maker for the development team on a day-to-day basis. A Change Manager rounds out the bridge team in larger initiatives, managing the human and organizational change that accompanies any significant new system.

The IT Side

On the technology side, the CIO or IT Director provides governance and strategic alignment, ensuring that IT initiatives serve the broader organizational strategy and that resources are allocated appropriately. The IT Manager or Delivery Manager oversees the project from the IT side, managing team capacity and delivery commitments.

The Solution Architect or Enterprise Architect translates the functional requirements produced by the business analyst into a technical design — defining the systems, interfaces, data structures, and technology components that will comprise the solution. This role requires both deep technical expertise and strong communication skills, as architects must explain technical trade-offs in terms that business stakeholders can understand.

Systems Analysts and Technical Analysts work below the architect level, converting the high-level solution design into detailed technical specifications that developers can implement. Developers and Software Engineers build the solution according to those specifications. QA Engineers and Testers verify that the built solution meets the documented requirements, using both automated and manual testing techniques. DevOps and Infrastructure Engineers deploy the solution to production, and IT Support staff ensure that end users can use the system effectively once it goes live.

The Flow of Requirements

The flow of information through this network of roles follows a recognizable pattern. The business sponsor communicates strategic intent to the business manager, who articulates the business problem to the business analyst. The BA works intensively with SMEs and end users to build a comprehensive picture of requirements, which is documented in a Business Requirements Document (BRD) or equivalent artifact. The solution architect uses this document to develop a Solution Architecture Document (SAD), which is then refined by systems analysts into detailed functional and technical specifications. Developers implement against these specifications, QA validates the output, and business users confirm that the solution meets their original intent through User Acceptance Testing (UAT). Only after UAT sign-off does the solution move to production deployment.

Each handoff in this chain represents both a communication opportunity and a risk point. Well-run IT organizations invest heavily in the quality of these handoffs — ensuring that documents are clear, reviews are thorough, and assumptions are explicitly documented and challenged. Organizations that treat handoffs casually, relying on informal conversations and tacit understanding, consistently experience higher rates of rework, delay, and ultimate dissatisfaction with the delivered solution.

Key Documents in the Translation Chain

The requirements translation process produces a series of documents that serve as the formal record of decisions made at each stage. While the specific names and formats vary by organization, the following artifacts are common across most industries and frameworks.

The Business Case documents the rationale for the IT investment, including the problem being solved, the proposed solution, the expected benefits, and the estimated costs and risks. It is typically prepared by the business sponsor or business manager and reviewed by senior leadership before a project is formally approved. The Business Requirements Document (BRD) captures what the business needs the solution to do — without prescribing how the technology should do it. A well-written BRD is technology-agnostic, focusing on business outcomes and functional needs.

The Solution Architecture Document (SAD) describes the technical architecture of the proposed solution, including system components, data flows, integration points, and technology choices. It is the primary output of the solution architect and serves as the master reference for all subsequent technical work.

Functional Specifications and Technical Specifications translate the architecture into detailed, implementable instructions for developers. User Stories and Acceptance Criteria, in Agile environments, serve a similar purpose in a more concise and iterative format.

Finally, the UAT Sign-off document formalizes the business's acceptance that the delivered solution meets its requirements — completing the translation cycle and marking the transition from project delivery to operational support.

Conclusion

The translation of business requirements into technology solutions is one of the most important and most frequently underestimated disciplines in modern organizational management. It is not a purely technical activity, nor is it purely a business one — it is fundamentally an act of communication, collaboration, and structured thinking that bridges two very different professional worlds.

Organizations that invest in this discipline — by hiring skilled business analysts, adopting proven frameworks, establishing clear governance structures, and cultivating a culture of rigorous documentation and review — consistently outperform those that treat requirements translation as an afterthought. The frameworks reviewed in this article, from BABOK and TOGAF to SAFe and business capability mapping, provide proven starting points that organizations can adopt and adapt to their specific contexts.

Ultimately, the most important ingredient is not a framework or a document template — it is a shared commitment between business and IT to communicate honestly, challenge assumptions respectfully, and remain focused throughout the process on the question that matters most: does this solution genuinely serve the needs of the people who will use it?

References

  1. International Institute of Business Analysis (IIBA). (2015). A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3. Toronto: IIBA.
  2. The Open Group. (2018). TOGAF Standard, Version 9.2. Reading: The Open Group. Available at: https://www.opengroup.org/togaf
  3. Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292.
  4. Scaled Agile, Inc. (2023). SAFe 6.0 Framework Reference Guide. Available at: https://scaledagileframework.com
  5. The Open Group. (2017). IT4IT Reference Architecture, Version 2.1. Reading: The Open Group. Available at: https://www.opengroup.org/it4it
  6. Wiegers, K., & Beatty, J. (2013). Software Requirements (3rd ed.). Redmond: Microsoft Press.
  7. Project Management Institute (PMI). (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th Edition. Newtown Square: PMI.
  8. Axelos. (2019). ITIL 4 Foundation. Norwich: The Stationery Office.
  9. Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy. Boston: Harvard Business School Press.
  10. Lankhorst, M. (2017). Enterprise Architecture at Work: Modelling, Communication and Analysis (4th ed.). Berlin: Springer.
  11. Cohn, M. (2004). User Stories Applied: For Agile Software Development. Boston: Addison-Wesley.
  12. Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston: Addison-Wesley.
LinkedIn

Tags: Opinion

96 reviews

Add comment