Abstract
This article examines recent developments in generative AI and emerging AI focused delivery roles, including the Forward Deployed Engineer, and their implications for business and technology investment decisions. Using infrastructure asset management as a practical example, we consider where Business Architecture can help organisations make better decisions, manage change across organisational boundaries and obtain more predictable value from technology expenditure.
AI assisted development, Software as a Service (SaaS), cloud technologies and forward deployed engineering can reduce the time, effort and, in some cases, cost required to turn business requirements into working technology. Organisations can explore ideas, configure applications, build integrations and automate work much faster than before. Management still has to determine which problems warrant investment, how proposed changes affect the organisation, and whether the resulting solution represents value for money.
These questions are particularly important in regulated and asset intensive organisations, where changes frequently involve operations, engineering, finance, risk, technology, procurement and assurance. The ISO 55000 series provides a useful setting in which to examine these relationships.
Business Architecture can assist with this work, but its contribution is neither automatic nor uniform. The quality of the practitioner, the client brief, access to organisational knowledge and the scale of the problem all affect its usefulness.
Faster implementation places greater demands on decision making
Generative AI is changing the pace and economics of business change.
SaaS platforms, AI assisted development, agile delivery and mature continuous delivery practices allow organisations to move from an idea to working functionality much faster than was previously practical. The Forward Deployed Engineer, a model closely associated with Palantir, takes this further by placing technically capable people close to operational users and giving them scope to understand problems and build solutions quickly.
This can make smaller interventions economical and shorten the distance between an operational problem and a working solution.
Business change can extend beyond the functionality being delivered. It may affect responsibilities, processes, controls, information, organisational capabilities and existing technology. A change requested by one function can create consequences for several others.
The ability to implement something quickly therefore places greater demands on the decisions that precede implementation.
Management needs to understand what problem is being addressed, whether it is material, which parts of the organisation are affected, what constraints apply and what benefits justify the expenditure.
Requirements rarely exist in isolation
A business requirement usually represents one view of a problem.
An operational team may have a clear understanding of what it needs from a system. That requirement can still depend on information owned elsewhere, affect a control operated by another function, duplicate an existing capability or alter responsibilities that were not apparent when the requirement was first described.
AI can accelerate analysis and implementation. It can also accelerate poorly framed work.
A technically successful solution may therefore address the immediate requirement while creating additional cost, risk or complexity elsewhere.
Business Architecture offers several ways of examining this wider context. Capability analysis can locate a requirement within the organisation rather than within a particular system. Process and information analysis can expose dependencies between functions. Current and future state analysis can help management understand what will actually change. Requirements can be related back to organisational objectives and the decisions they are intended to support.
The usefulness of this work depends on the problem being examined and the quality of the analysis.
Regulation increases cross functional dependencies
Regulated industries provide particularly clear examples.
Infrastructure, utilities, financial services and other regulated enterprises operate through obligations that cross departmental boundaries. A significant change may involve Operations, Engineering, Finance, Risk, Procurement, Technology, Data, Legal and Assurance. Regulators, suppliers and other external parties can introduce further requirements.
Consider an operational team that identifies an opportunity to automate part of its work.
A Forward Deployed Engineer can work alongside the team, understand the immediate problem and create a useful solution quickly. The solution may use information governed elsewhere. Finance may require controls around expenditure or transactions. Risk may need evidence about automated decisions. Technology teams may have security and integration requirements. Another operational function may depend on the process being changed. Regulatory reporting may depend on evidence previously produced through the manual process.
Each of these considerations can affect the design and economics of the proposed change.
For a small and contained intervention, the people involved may be able to resolve these matters directly. As the number and significance of dependencies increase, a structured view of capabilities, responsibilities, information and processes becomes more useful.
This is one setting in which Business Architecture can contribute to better investment and implementation decisions.
Enterprise Asset Management as a practical example
Enterprise Asset Management illustrates the problem because infrastructure assets are managed through activities distributed across much of an organisation.
Operations needs assets capable of delivering required services.
Engineering needs reliable information about condition, performance, criticality and failure.
Finance needs credible expenditure and investment forecasts.
Risk and assurance teams need evidence that material risks are understood and controlled.
Procurement has to consider suppliers, contracts and lifecycle requirements.
Technology and information teams maintain the systems and data that support these activities.
Senior management has to make investment and service decisions using information produced across this environment.
An apparently local improvement can therefore have a long chain of dependencies.
Improving maintenance planning may require better asset information. Improving asset information may require changes to data ownership and field processes. Investment planning may require engineering assessments to be expressed in forms that Finance and management can use. Regulatory reporting may depend on evidence generated throughout this chain.
An EAM platform can support these activities. AI and predictive analytics can extend what can be done with the information. The quality of the investment still depends on how well the organisation understands the relationships between assets, information, responsibilities, decisions and business objectives.
ISO 55000 and organisational capability
The ISO 55000 series provides a useful reference point because asset management is concerned with the coordinated activity of an organisation to realise value from assets.
For an infrastructure organisation, applying these principles reaches well beyond the asset management system or EAM application.
Asset information has to support decisions. Responsibilities have to be understood. Investment planning has to connect with service objectives and risk. Operational activity has to relate to asset strategy. Assurance requires credible evidence. Technology has to support these relationships over the asset lifecycle.
This often exposes differences between organisational functions.
Teams may use different definitions, maintain different records and make decisions at different stages of the asset lifecycle. Existing systems may reflect historical organisational boundaries. Responsibilities may have developed through practice rather than deliberate design. Information needed for an investment decision may originate several processes and departments away.
These conditions have direct consequences for technology expenditure. A new platform introduced into an unresolved information or management environment can reproduce existing problems in a more sophisticated system.
Business Architecture can help management examine the underlying capabilities, information requirements and dependencies before deciding what should be changed and where technology investment is justified.
AI and the Forward Deployed Engineer
AI expands the range of changes that organisations can undertake economically.
It can assist with analysis, specification, software development, information processing and automation. Forward deployed engineering reduces the distance between operational users and people capable of implementing solutions. SaaS platforms provide mature capabilities without requiring organisations to develop every component themselves.
These developments can be particularly valuable where organisations have accumulated small operational problems that were previously too expensive to automate or integrate.
They also change the balance between analysis and implementation.
When implementation was slow and expensive, organisations had considerable time to discover dependencies during a project. Faster delivery can bring an incomplete requirement to implementation before those dependencies become visible.
A Forward Deployed Engineer therefore benefits from good organisational context. The engineer needs to know which capability is being changed, which information is authoritative, which controls apply, who has decision authority and what consequences the change may create elsewhere.
Business Architecture is one source of that context. Experienced operational staff, process owners, risk specialists, enterprise architects, data professionals and other disciplines may provide equally important knowledge.
The practical requirement is to assemble enough of that knowledge to make a sound decision without turning analysis into an obstacle to delivery.
Limits of Business Architecture
The quality of Business Architecture work varies considerably.
An experienced practitioner working from a well framed brief and with access to the people who understand the organisation can identify relationships that materially improve a decision. Poorly framed work can produce extensive models and documentation without doing so.
The client shapes the result as well.
Important constraints may sit outside the original brief. Stakeholders may describe the same problem differently. Existing documentation may not reflect current practice. Organisational boundaries can restrict access to information. Management may already have committed to a solution before the analysis begins.
Practitioner judgement matters because no model contains the whole organisation. Decisions have to be made about what to investigate, what level of detail is useful and which dependencies are material to the decision at hand.
There is also a question of proportionality.
A contained operational problem with understood dependencies may require little formal architectural analysis. Adding architecture to such work can increase cost without improving the result.
A change involving several functions, significant investment, regulatory obligations, important information dependencies or difficult to reverse decisions warrants more attention.
The amount of Business Architecture work should reflect the decision being made and the consequences of getting it wrong.
Business Architecture and decision quality
For senior management, the useful output of Business Architecture is not the architecture itself.
Its value lies in the decisions it helps people make.
A capability model may reveal that several proposed technology projects address different symptoms of the same organisational problem. An information model may show that a proposed automation depends on data that cannot currently support the decision. Current and future state analysis may expose responsibilities that have to change before a new system can operate effectively. Requirements analysis may identify a cheaper way of achieving the required business outcome.
These findings can affect scope, priorities, sequencing, procurement and investment.
They can also provide reasons not to proceed with a proposed technology intervention.
That is an important part of value for money. Better technology investment is partly about choosing and implementing useful solutions. It also involves avoiding expenditure that does not address the underlying problem.
From organisational intent to executable change
Essence Networks approaches Business Architecture from this decision context.
We begin with the client’s frame of reference and the decisions the organisation needs to make. We work across organisational boundaries where the problem requires it, and develop enough detail to connect management objectives with capabilities, processes, responsibilities, information and requirements.
The level of analysis depends on the engagement.
For some problems, a relatively small amount of structured analysis is sufficient to clarify the requirement and allow implementation to proceed. More consequential changes may require deeper examination of current and future states, dependencies, controls and organisational capabilities.
Our work draws on experience in regulated industries, business analysis, corporate finance, governance, technology and assurance. This helps us examine technology requirements in the context of the business decisions and obligations they support.
We work with client management, operational teams, internal ICT functions and vendors. This allows requirements and implementation choices to be tested against different organisational perspectives while retaining a clear connection to the original business purpose.
We are vendor independent. Technology choices can therefore be assessed against the client’s requirements, constraints and interests rather than a preference for a particular product or supplier.
As AI and faster engineering reduce the cost of implementation, organisations will have more opportunities to use technology to change how work is performed. Selecting the right problems, understanding their organisational context and making sound investment decisions will remain management responsibilities.
Business Architecture can help with those responsibilities when it is applied with judgement, proportionately, and in service of the decisions that need to be made.