The Guide to Practical and Pragmatic IT Architecture Design

Input to IT Architecture: Functional Requirements

The most important question when designing an architecture is what is guiding the design of a Technology Architecture? To start with designing a good architecture, one needs to understand the very basics of what the architecture must accomplish. Not only for what it has to achieve now, but also for the next 3-5 years horizon if not longer. 

To understand the needs, the architect needs to understand the overall vision and company guidance and identify the requirements for the application. 

Take the example of designing a building: For a building, the architect needs to determine whether the building will be for residential, office or factory use (vision). It needs to comply with certain regulations and city planning guidance to fit in the urban landscape (guiding principles). And then it needs to determine how many people will use the building now and in the next years, how many floors, its specific purpose, use of utilities and many other things (requirements). If the building cannot handle the number of floors or people, it may collapse. On the other hand if it is built to big, it may be too expensive and impractical. 

The same applies to understand properly the requirements for a IT architecture. 

Functional Requirements Software


To determine the input to Technology Architecture, requirements need to be analyzed. There are 2 kinds of requirements that shape the input for technical application design: 
Gathering these requirements is an iterative process and can be obtained by interviewing key stakeholders or provided by a initial high level blueprint.
In the first iteration, the focus is on the most relevant inputs that gives an answer to the main considerations for this application. Once main architectural decisions have been made, the requirements need to be more detailed to do the detailed design and architecture implementation.

Example: Starting with the security requirements analysis, one needs to understand whether the application will be accessed within company premises or can accessed through the public internet. For a high-level analysis, it is sufficient to determine that the application will be exposed on the public internet and as a result, the high-level design needs to include a public security architecture component. In the detailed design, more detailed requirements need to be established such as what types of users, in which locations, and through which channels the application will be accessed.
The following sections clarify the types of requirements and what details need to be gathered for the analysis phase. 

Functional Requirements

Functional requirements are the needs of what an application needs to accomplish from a business or functional perspective. An example is that an application has to provide loans or selling airline tickets. 
These functional requirements do provide input to the overall technical application design as its purpose could direct the way an application needs to be built. 

Functional requirements are also known as non-technical requirements (NFR) or business requirements. Even though not all functional requirements are required and provide input to the IT architecture fundament, there are some of these non-technical requirements that are key to application design. Listed below are some examples application types and considerations need may impact the IT architecture design:

 Application Type Application Architecture and considerations
 Core Application such as Supply Chain, banking, SalesA core application is typically the center of what the company does. It is based on products and transactions (e.g. selling, ordering, manufacturing, maintaining, shipping a product) and has clients to whom they sell finished products to and suppliers from whom they order raw materials or products. Transactions are managed within the application and may connect to various surrounding satellite applications.

Example:A company that sells tickets will have to be constructed with a focus on front-end web, mobile channels or other channel accessibility and an interaction and integration layer with existing backend systems. 

Considerations: Type of Industry (financial, manufacturing, transport, communications, etc), Need of flexibility in orchestrating Business Processes & parametrizing, Interconnectivity with devices or other applications, Need for batch processing, Need for output management such as printing
 Customer Relationship Management (CRM)Customer relationship Management systems are built on a client database and campaign management capabilities to increase customer conversions. Typically, it is connected to a sales application.

Considerations: Sales Channels (e.g. web. Mobile, kiosks, ATM etc), Need to get same user experience for multiple channels (multi channel and omni channel requirements), Interconnectivity with devices or other applications 
 Data WarehouseA data warehouse application has a strong focus on data and large data repository for structured data or data lake for both structured and unstructured data. It needs strong analytical and reporting capabilities to analyze data.

Considerations: Type of data (eg. Structured vs non-structured), Real-time vs non-realtime
 Digital Asset Management  This could be a document, content or digital asset management system, that manages and structures content with metadata. It should provide fast access and a strong data structure to find and manage assets.

Considerations: Types of digital assets, Real-time vs non-realtime

There are other types of applications, but the list would be too extensive. Applications can cover one of these application types or multiple. For example, a full-fledged core can contain sales, data warehouse, as well as an asset management system and depends on scope.

In the next section we review technical requirements.

No comments: