Functional Architecture as a discipline has been brewing for a few years now. I have been a “functional architect” for a software application, and have also been involved in functional architecture review of enterprise software programs. I won’t claim to know what functional architecture means in any universal sense, but having done this work, and been in this role, I can describe some functional architecture principles that I know are helpful to making software more valuable in an enterprise context.
Functional architecture has several aspects.
Semantic Principles of Functional Architecture
“Understand the work that needs to get done, regardless of technology, process, or organization structure.”
- Units of Work – Identify and define the units of work that the user will accomplish through the application’s capabilities. Define the units of work that the system will accomplish without user interaction. Define the units of work that the system will demand of the user to remain operational. (This is a process model)
- Decisions – Identify and define the decisions involved in each unit of work. (This is the operating model)
- Specific Components – Identify and define the components that compose, describe, or modify each of the units of work. (This is a component model)
- Specific Behaviors – Identify and define the desired or prohibited behaviors of each component relative to each of the units of work. (This is a behavioral model)
- Specific Information – Identify and define the required information to inform the behaviors and enable the components and decisions related to each unit of work. (This is an information model)
Boundary and Integration Principles of Functional Architecture
“Encapsulate each unit of work within a single application, platform or system”
- Delegations and Notifications – interfaces should be designed as contractual delegations or notifications, not conversations. A conversation that extends beyond a two-phase commit is an abomination.
- Minimize Hand-offs – A software capability should be located (added to an application) so that the control of a departmental business process or work flow is “passed” from one application to another, the least number of times. (It is fine for a department to use two applications for two different processes, but not to use two applications to finish one process.)
- Publish and Subscribe – publish information created in each application, so that it can become available to the enterprise. Subscribe to enterprise data sources, rather than maintaining data sources specific to the application, or forcing users to run other applications to get necessary information.
User Experience Principles of Functional Architecture
“Focus user experience around the accomplishment of specific units of work.”
- Task Atomicity – The steps required to complete a task or step in a business process should not be divided across applications or systems.
- Decision Focused – The information normally required by users to make decisions related to the work (task, step, process) should be directly displayed, or readily available within the application that is managing the work.
- Momentum – The application should always make the user feel that they are making progress. Prevent forcing the user to “start over” on tasks as much as possible.
Operating Model Principles of Functional Architecture
“Focus the organizational model to concentrate responsibility for each unit of work within a single organizational unit.”
- Concentrate Responsibility – Make one person or department responsible for a unit of work, so that accountability for throughput is natural.
- Define Contracts – When hand off’s between individuals or departments are necessary, define clear contracts, so that accountability is clear.
- Minimize Feedback Loops – The need for a feedback loop indicates that accountability is shared, use this to identify operating model challenges.
No Comments