The 4 Phases of Successful Bidding Reply

ICT deals are unlike other technical deals. Whilst engineering deals may be ‘complicated’ with their detailed technical details, ICT deals are often exponentially more ‘complex’ because they blend loose business concepts with technical specifications. Technical success is pegged to business benefits or unknown end states at the end of lengthy business transformations based on multiple increments of capability. For this reason the standard Colour Phases of bid development do not adequately support large, complex ICT deals. Robust process is a must in order to ensure adequate cross-functional collaboration across large, dispersed organisations. However, tech deals need to evolve through iterative stages of architectural development. The diagram below sets out a colour phased development lifecycle for large and complex tech deals. In this way, they get the process to manage the organisational governance as well as the architectural focus necessary to develop a winning value proposition.

THE ISSUE

The issue is never designing the solution it is unpicking it. Tech deals are not only complex they are aggregations of complexity: security systems, infrastructure, applications, business rules, benefits, integration – it all develops in isolation and it all has its own logic and its own costings and commercial parameters. It does, however, all work together. So, when it comes to the end of the bid and the team have to reduce costs in order to hit their estimated price-to-win it is somewhat akin to playing a giant game of “Kerplunk“. Straw by straw the architecture is unpicked and all the stakeholders around the metaphorical table just hold their breath and hope that not all the marbles fall down. If they don’t it is pure luck.

Technical ICT architectures are not like normal technical engineering projects or other capital works. The customer is not building an independent means of production. ICT (less robotic systems, i.e. embedded technology) is an integral and entwined part of business capability. It is inextricably linked to the business. If the dots are not all joined at the outset of the bid then when it comes to reducing costs at the end, the executives will strip down random parts of the technical solution which is usually the foundation of the value proposition. What will be left is a patchy solution that has obvious structural weaknesses (to the intelligent customer).

THE PROBLEM

The problem is how to design elegant and sophisticated architectural solutions within cost, commercial and time parameters. The individual system components will be designed in splendid isolation with a variety of assumptions and guesses. The entire solution, however, needs to be designed, costed, stress-tested and reviewed within tight timeframes and against aggressive price points. In order to lead a large and disparate (often virtual) team to achieve these goals will take a robust process and a strong personality exerting herculean effort. The crux of the matter is how to manage varied personalities through a convoluted development process without stifling the elegance of the design yet still manage to corral such strong temperaments through tight review gates.

THE SOLUTION

The solution is a blend of both the traditional colour-phased bid structure and the complexities of the architectural development process. Together it might be referred to as Colour-Phased Architecture. In this way the bid team are cognisant and appreciative of the subtleties and complexities of the architectural design process and the executive get a strong process which even the strictest governance may rely on.

THE PROCESS

Adapting Krutchen’s 4+1 Views the architecture is developed through 5 critical structures:

  • Use Cases. The Customer narratives and scenarios are developed to produce and update the various iterations of the architectural solution.
  • Architecture. The solution should develop through 4 iterations:
    • Logical – This will ensure that it is anchored by the strategy and accurately reflects it.
    • Physical – This is where specific solutions are developed and the tighter parameters are loaded.
    • Transition – This addresses the specific issues around the deployment, transition and change management issues for the customer.
    • Transformation – The vendor should make the majority of the margin during this phase and so much of the strategy, modelling should focus on the incremental capability uplifts. This is where the primary benefits realisation management should focus.

Architectural Development

The architecture of the solution is defined by a careful communication between elements. The interaction between the structural colour-phases and the functional solution development supports this in two ways: (i) the Use Cases inform the design of the solution, and (ii) the phases inform the development of the solution. Initially, the customer use cases determine solution design. The solution must be derived from a desire to solve the customer’s problem. A list of requirements is essential and usefully but may only result in a patchwork quilt of technical components and business benefits. The logical solution will then be molded and developed using the vendor strategy and broad parameters.

The physical solution along with more detailed attention to the Transition and Transformation stages is then pushed through another 3 phases of development. In this way, the team ensures that the architecture is not only technically comprehensive but that it is a sensible, well costed solution that will meet the customer’s needs well into the future.

Process Colour-Phases

The colour phases are essential because without them the architectural development process would just spiral out of control. The colour phases ensure:

  • that the development of the solution occurs within a structured governance framework,
  • that there is cross-functional collaboration between the technical silos and the commercial support, and
  • that the progress of development is measurable and communicable to the non-technical executive.

To that extent there are 4 essential phases to ensure that the technical solution does not exist in splendid isolation but is a well costed, commercially sensible plan to make money by delivering something which plays to the vendor’s strengths whilst delivering something of real value to the customer. In order to do that the process must ensure it develops:

  1. Strategy. The strategy must be developed from the outset. Architecture is not strategy. Without strategy there is nothing to anchor the technical development with and nor is there anything to prod and cajole business partners with.
  2. Architecture. Solution development is only part of the process. As with any design process, the artistic talents and temperaments of the team must be constrained and focused.
  3. Commercials. The commercials have to be right. No matter how elegant or sophisticated the solution, unless it works commercially it will not be signed off.
  4. Viability & Review. The solution must be able to be reviewed internally by peers and colleagues. It must exist as a coherent body of documents (which will be pulled together into the bid document). The team must be able to prove that the solution will work over the long term and exist as a part of the customer’s enterprise architecture.

There is both art and science in the design, development and management of large and complex bids. Bids team not only require the gravitas of deep technical ability but also leadership and communication skills. Without these the solution will not be balanced but rather a mess of technical solutions competing to over-deliver functionality. There is no easy way to navigate the issue but a colour-phased process of architectural development blends the best of both worlds into a practical and deliverable lifecycle.

Figure 1 – A colour-phased lifecycle for technical bids.

Benefits-Led Contracting: no immediate future for outcome based agreements Reply

The IACCM rightly points out that key supplier relationships underpinned by robust and comprehensible contracts are essential to the implementation of significant strategic change.  Their research identifies a 9.2% impact on bottom line from contract weakness.  Top 5 causes being:

  •      Disagreement over contract scope,
  •      Weaknesses in contract change management,
  •      Performance failures due to over commitment,
  •      Performance issues due to disagreement over what was committed,
  •      Inappropriate contract structures or responsibilities.

Two things are given in this mess:  (i) Firstly, that contractual structures are weak and inappropriate to deal with high levels of operational complexity and technical risk, and (ii) secondly, that legal means of enforcement are cumbersome, expensive and ineffective.

That business is ready to solve this legal problem by contracting for outcomes is (a) nonsense and (b) missing the point.  Business is already dealing with the operational and technical risk of large and complex contracts.  Business is already structuring many of its agreements to deal with outcomes.  Large prime contracts,  alliance contracts and performance-based contracts are already commonplace in PFI/PPP and Defence sector deals.  That neither are wholly efficient or effective is for another time.  It is, however, for the legal community to devise more sophisticated ways of contracting in order to solve their side of the problem.

Picture1

PEOPLE ARE THE KEY

The primary reason for not being able to contract for outcomes is that the vendor doesn’t own the people.  This is critical because without the ability to control and intervene in the delivery of work the risk increases exponentially.  Consequently, the risk premium paid for outcome-based contracts will either make them (a) prohibitively expensive, or (b) impossible to perform (within parameters).  So, a business which offers you an outcome-based contract is either having you on or just about to charge you the earth.

 

 

Competitive Advantage in IT 1

Although a recent article in SearchCIO alludes to competitive advantage by IT departments, arguments like this can take the CIO down a dangerous road.  The holy grail of many CIOs is to run a department which is both profitable and also increases business capability.  Mostly, however, IT departments are costly and the subject of constant complaint.

Can IT ever be a profit centre?

Economists have long argued that businesses should strip away overhead (i.e. not included in the cost of goods sold but pure overhead) cost chargebacks from business verticals and their processes in order to gain a clearer view of what is profitable and what is not.  If they don’t then smaller, profitable processes are often in danger of being swamped with overhead.  In this way, many businesses often outsource or cut the wrong activities.

It is notoriously difficult to cost IT chargebacks so that market verticals are charged just the right overhead.  Should businesses charge their verticals for email?  They often do but isn’t this just a cost of business that the centre should absorb?  Isn’t the burden of communication and reporting largely placed onto verticals anyway?  So if they could run their business units in a more entrepreneurial way wouldn’t the cost of IT be significantly reduced? 

What if we extend that argument and let IT be a profit centre?  Why don’t we let business units find cheaper ways of doing business and compete with the IT department?  Security/integration/management time arguments aside – it is likely that if IT departments were able to charge for the thing they were really good at, this would be a source of competitive advantage within the business.

So, there is a good reason why IT departments aren’t profit centres but, of course, this doesn’t solve the problem of the high cost of IT inside business.

Getting Rid of the Help Desk–a structured approach to KM 1

In a recent article in CIO magazine Tom Kaneshige argues that the rise of BYOD spells the demise of the traditional Help Desk.  He intimates that BYOD has now been overtaken by BYOS – bring-your-own-support!  The network-enabled user, with access to huge volumes of information, requires a new Help Desk. 

He is right that, ultimately, power-users need better, faster support delivered to them in a format and by people with a deeper understanding of the context and with more intricate solutions.

BYOS is the exception and not the rule. 

Although the IT function is becoming more commoditised, the larger fields of knowledge work isn’t, hasn’t and won’t be commoditised anytime just yet.  Otherwise, any 12 year old with a laptop would be in with a chance.  Help Desks don’t need to be expanded but they do need to become more mature, agile and integrated into the KM procedures of modern networked enterprises (ie those businesses with a heavy KM focus).  Expanding the remit of the Help Desk opens the door for colossal cost increases.  Internal knowledge management functions need to become more structured beyond simplistic portals.

INTERNAL KNOWLEDGE MANAGEMENT

In a recent article in McKinsey Quarterly, Tom Davenport argues that organisations need to get a lot smarter in their approaches to supporting knowledge workers.  He says that greater use of social media and internet use will harm the business more than help it.  Lower level knowledge workers need more structured support to their processes.  On the other hand, high-level knowledge workers are better supported by an open platform of tools.  Getting the right balance is as much art as science.

BYOS is the wrong approach.  It’s a derogation of KM responsibilities.  Organisations need to focus on an approach to KM with the following structures:

  1. A good Help Desk function for knowledge workers involved in highly structured processes.
  2. An IT function which supports a flexible arrangement of tools for advanced knowledge workers.
  3. Knowledge Managers:  people who provide the focal point for certain areas of knowledge.
  4. Portals:  A single entry point for people seeking access to communities of interest.

So, be careful when thinking about Tom Kaneshige’s advice and “blowing up” your Help Desk.  IT can be a self-licking lollipop.  More tools and more information won’t necessarily improve productivity.  At the lower level, sometimes it makes more economic sense to support the process.  It’s only at the upper levels of expertise that it is more profitable to support the person.

Sometimes the best defense is deletion – CSO Online – Security and Risk Reply

Sometimes the best defense is deletion – CSO Online – Security and Risk.

data mining. big dataThe point is prescient.  In these early days of Big Data awareness the battle between information management v. store now/analyse later can obfuscate other issues:  Cost and Necessity.

ONE BIG POT

Is there really the practical technology that an organisation can actually move away from structured databases and just stick all its information into one big ‘pot’, to be mined for gold nuggets at a later date?

Storing information (as opposed to just letting stuff pile up) is a costly business and the decision to store information usually comes from people on higher pay bands.  The decision of where to locate is often a manual decision which not only has a significant management overhead of its own but also involves co-ordination from other high pay bands.

THE COMPLEXITY OF INFORMATION

Picture1

Add to this dilemma the complexities of  ‘legal hold’ on material and the identification of ‘discoverable’ items.  Suddenly information management looks a lot harder and the siren song of Big Data seems a lot more alluring.  The problem is that information that is not valuable to some is valuable to others.  Who is qualified to make that decision?  Should all information be held given that it will likely have some enterprise value?  The battle is between cost and necessity:

  1. Cost:  Deciding what to keep and what to get rid of takes management time and effort that costs money.  The problem is that it is neither cost effective nor good policy to to push hold/delete decision making down to the lowest clerical level. The secret is to have those decisions made by more senior case-workers but only within their limited remit.
  2. Necessity:  The secret is to categorise management information to determine necessity.  Use a workflow to cascade and delegate (not to avoid) work.  As it moves it accumulates metadata.  No metadata means no necessity and therefore it should be disposed of automatically (eschewing arguments of regulatory compliance).

THE ANSWER

The answer is to automate the deletion of information (other than ‘Legal Hold’).  Once a document/question has reached the end of the workflow without accumulating any metadata then the information should be disposed of automatically.  Case-Workers make the decisions to act on the document/question and metadata is attached by more clerical staff (on lower pay bands) as the item moves through the workflow.  If no metadata is attached it can be assumed that the item is not important and is therefore disposed of.  Cost is minimised by letting case-workers make decisions of relevance within their own sphere of expertise without the additional management overhead for de-confliction/meetings etc.   In this way, the enterprise makes a collective decision of importance and stores the information accordingly thus answering the issue of necessity.

Improving Contract Management: manage the deal not the database 1

The guys at Selectica have some great points but to make expensive enterprise software work it’s important to work a system and not to work the software:

  1. Don’t try and put all your contractual information in one single database at once.  Not only do individuals have different ways and systems (what I call the e-Hub of someone’s daily life) from which they manage their data they may also run into legal issues around probity and confidentiality (by cross-contaminating case management with archival material).  Businesses do not need to invest in costly customisation but do need to strike a financial balance between customisation and counter-intuitive vendor processes.  One neat tool is to create  a visual model of the deal (its structures, functions and concepts) and provide hyperlinks to the various file systems.  This removes the need to develop a common taxonomy as workers now have a visual reference point (rather than a word) for their own understanding.
  2. With process automation it is critical to ensure that the business doesn’t  codefy its culture.  This will only calcify bottlenecks.  A firm needs to make sure that it re-engineers its CLM process before it creates a workflow from it.  Remove non-tasks and automate simple clerical work and approvals.
  3. The business also needs to make sure that experts are not only notified but they are also edified  and contextualised.  When pushing workflows out to experts, such as in-house counsel, outside counsel etc then these people must have a clear view of the dependent components of the deal’s architecture.  Businesses can speed this process and reduce its costs by linking their own systems to online legal databases such as Thomson Reuters (Westlaw AU, FirstPoint), Lexis Nexis or CCH.

In summ, good contract management needs a highly cross-functional and multi-disciplinary approach if it is not only to be successful but also if it isn’t going to add additional cost and friction to business operations.  Enterprise products such as Selectica’s are a great start but customers must be careful to make sure that the software supports their own system otherwise they will spend all their money and time working the software.

Building a Risk Culture is a Waste of Time 3

The focus of a good risk management practice is the building of a high-performance operational culture which is baked-in to the business.  Efforts to develop risk cultures cultures only serve to increase risk aversion in senior executives and calcify adversarial governance measures which decrease overall profitability.  The right approach to risk management is a comprehensive, holistic risk management framework which integrates tightly with the business.

risk management. waste of timeThe financial crisis is largely due to the the failure of risk management and over-exposure in leading risk-based institutions.  More specifically, the failure of risk management is linked to:

  • The failure to link link risk to investment/project approval decision making.  The aim of risk management is not to create really big risk registers.  Although, in many organisations one could be forgiven for thinking that this is the goal.  The aim of identifying risks is to calibrate them with the financial models and program plans of the projects so that risks can be comprehensively assessed within the value of the investment.  Once their financial value is quantified and their inputs and dependencies are mapped – and only then – can realistic and practical contingency planning be implemented for accurate risk management.
  • The failure to identify risks accurately and comprehensively.  Most risk toolsets and risk registers reveal a higgledy-piggledy mess of risks mixed up in a range from the strategic down to the technical.  Risks are identified differently at each level (strategic, financial, operational, technical).  Technical and Operational risks are best identified by overlapping processes of technical experts and parametric systems/discrete event simulation.  Financial risks are best identified by sensitivity analysis and stochastic simulation but strategic risks will largely focus on brand and competitor risks.  Risk identification is the most critical but most overlooked aspect of risk management.
  • The failure to use current risk toolsets in a meaningful way.  The software market is flooded with excellent risk modelling and management tools.  Risk management programs, however, are usually implemented by vendors with a “build it and they will come” mentality.  Risk management benefits investment appraisal at Board and C-Suite level and it cannot be expected to percolate from the bottom up.

RISK MANAGEMENT IS COUNTER-INTUITIVE

All this does not mean that risk management is a waste of time but rather it is counter-intuitive to the business.  It is almost impossible to ask most executives to push profits to the limit if their focus is on conservatism.  Building a culture of risk management is fraught with danger.  The result is usually a culture of risk aversion, conservatism and a heavy and burdensome governance framework that only adds friction to the business lifecycle and investment/project approval process.  Executives, unable to navigate the labyrinthine technicalities of such a systems achieve approvals for their pet programs by political means.  More so, projects that are obviously important to the business actually receive less risk attention than small projects.  Employees learn to  dismiss risk management and lose trust in senior management.

If risk management is to be an effective and value-adding component it must be a baked into the business as part of the project/investment design phase.  If not, then risk management processes  just build another silo within the business.  The key is to forget about “Risk” as the aim.  The goal must be a performance culture with an active and dynamic governance system which acts as a failsafe.  The threat of censure is the best risk incentive.

risk management. immature disciplineAWARENESS IS NOT MANAGEMENT

risk management. immature disciplineManagement has long been aware of risk but this does not always translate into true understanding of the risk implications of business decisions.  Risk policies and practices are often viewed as being parallel to business and not complimentary to it.

Why is it that most businesses rate themselves high on risk management behaviours?  This is largely because businesses do not correlate the failure of projects with the failure of risk and assurance processes. 

In a 2009 McKinsey & Co survey (published in June 2012 “Driving Value from Post-Crisis Operational Risk Management”) it was clear that risk management was seen as adding little value to the business.  Responses were collected from the financial services industry – an industry seen as the high-water mark for quantitative risk management. 

COLLABORATION IS THE KEY

Risk management needs to become a collaborative process which is tightly integrated with the business.  The key is to incentivise operational managers to make calculated risks.  As a rule of thumb there are 4 key measures to integrate risk management into the business:

  1. Red Teams.  Despite writing about collaboration the unique specialities of risk management often requires senior executives to polarise the business.  It is often easier to incentivise operational managers to maximise risks and check them by using Red Teams to minimise risks.  Where Red Teams are not cost effective then a dynamic assurance team (potentially coming from the PMO) will suffice.  Effective risk management requires different skills and backgrounds.  Using quantitative and qualitative risk management practices together requires a multi-disciplinary team of experts to suck out all the risks and calibrate them within the financial models and program schedules in order that investment committees can make sensible appraisals. 
  2. Contingency Planning.  Operational risk management should usually just boil down to good contingency planning.  Due to the unique skill sets in risk management, operational teams should largely focus on contingency planning and leave the financial calibration up to the assurance/Red teams to sweep up.
  3. Build Transparency through Common Artefacts.  The most fundamental element of a comprehensive  risk process is a lingua franca of risk  – and that language is finance.  All risk management tools need to percolate up into a financial model of a project.  This is so that the decision making process is based on a comprehensive assessment and when it comes to optimise the program the various risky components can be traced and unpicked.
  4. Deeper Assurance by the PMO.  The PMO needs to get involved in the ongoing identification of risk.  Executives try and game the governance system and the assurance team simply does not have the capacity for 100% audit and assurance.  The PMO is by far the best structure to assist in quantitative and qualitative risk identification because it already has oversight of 100% of projects and their financial controls.

Traditional risk management practices only provide broad oversight. With the added cost pressures that businesses now feel it is impossible to create large risk teams funded by a fat overhead. The future of risk management is not for companies to waste money by investing in costly and ineffective risk-culture programs.  Good risk management can only be developed by tightly integrating it with a GRC framework that actively and dynamically supports better operational performance.

ALIGNMENT: Building a Closer Relationship Between Business and IT Reply

alignment. team workjpgThe business gurus Kaplan and Norton describe “Alignment” as a state where all the units of an organisational structure are brought to bear to execute corporate strategy in unison.  When Alignment is executed well it is a huge source of economic value.  When it is executed badly it is a colossal source of friction which can cripple the business.  The authors go on to note:

Alignment

IT DOESN’T NEED ALIGNMENT, IT NEEDS BETTER UNDERSTANDING

IT and the Business speak of alignment in two radically different ways.  The Business talks about alignment between business units.  When speaking of tech they use words and phrases such as ROI and operational performance.  IT talks about alignment in a way that makes them feel as though they matter to the business.  That profitable, customer facing business units could achieve more if the corporate centre where to align business units under a single, cohesive strategy is one thing.  That IT depts fail to execute strategy or even deliver operational effectiveness through poor understanding of requirements, an inability to see the technical reality of commercial value or realise some of the social cohesion which enterprise software systems need is not mis-alignment – it is just bad practice.

THE RELATIONSHIP BETWEEN THE BUSINESS AND ICT IS DIVERGING

The increasing capabilities of a smarter, more mobile , more virtual workforce means a greater commoditisation of knowledge work.  With this comes the polarisation of Business and ICT.   A broader ICT function with a wider array of narrower and deeper areas of expertise will, increasingly, be incapable of coding the more subtle and complex social aspects of human collaborations.  In such a world the ICT agenda must be set by the corporate centre.

mis-alignment

ICT NEEDS TO FOCUS ON EXECUTION NOT ALIGNMENT

ICT’s economic value will be realised when it (and therefore Enterprise Architects) can support business units to reach across each other to create valuable products and services which justify the corporate overhead.  McKinsey & Co, for instance focus heavily on central knowledge management.  This enables research to drive service line improvement in relevant sectors.  IBM spends over 3 Bn GBP on R&D and the development of leading-edge products way beyond their years.  ICT needs to focus on the execution of corporate strategy and not alignment. Alignment is a structural issue whereas execution is a functional issue.  Stop tinkering with the structures and focus on the functions/operations.

GOVERNANCE – ALIGNMENT AT A PRICE

Moves to improve the business relevance of ICT usually result in heavier, more burdensome technical governance.  The finance function imposes capital project controls on technology projects and insists that benefits be quantified.  Although greater cost transparency will bring IT closer to the Business, heavier ICT governance only serves to drive ICT investment underground.  Pet-projects abound, useless apps proliferate and ICT costs continue to rise.  In the meantime, in a perverse inverse relationship, assurance becomes even lighter on larger programs. 

Alignment takes strong leadership and clear definitions of business intent.  A fancy set of IT tools are not necessary for alignment rather they are important when it comes to agilityMis-alignment is the fault of deep rooted cultural divisions which can only be overcome through the strict adherence to financial value and the use of a lingua franca engendered through a common architectural framework.   If ICT is to realise its potential and add real financial value then it must actively support the real-time execution of business operations.

BUSINESS PROCESS FAILURES: the importance of logical architectures Reply

business process risk. chart

In a recent 2012 survey by McKinsey & Co, IT executives noted that their top priorities were ‘improving the effectiveness and efficiency of business processes’.   One of the critical failings of IT, however, is to implement effective and efficient business process architectures in the first place.  The IT priorities to the left only serve to highlight what we already know:  that IT service companies implement processes badly.

Why?

Whether through a failing of Requirements or Integration (or both), IT service companies often implement inappropriate business process architectures and then spend the first 6 to 12 months fixing them.  This is why those companies ask for a 6 month service-credit holiday.  It is also the same reason those companies differentiate between Transition and Transformation.  The former is where they implement their cost model but the latter is where they implement their revenue model.

The failing is not within the design of the technical architecture.  Very few senior executives report that failed projects lacked the technical expertise.  Likewise, project management is usually excellent.  Requirements, too, are not usually the problem with business process implementations as most commercial systems implement standardised Level 1 or 2 business processes very well.

Logical Archtiectures instantiate the subtleties and complexities of social systems which the software must implement

The first failing in the development of a technical architecture to implement a business processes is the design of the Logical Architecture.  Logical Architectures are critical for two reasons: (i) because requirements are one hundred times cheaper to correct during early design phases as opposed to implementation, and (ii) because logical systems are where the social elements of software systems are implemented.  Requirements gathering will naturally throw up a varying range of features, technical requirements, operational dependencies and physical constraints (non-functional requirements) that Solution Architects inevitably miss.  Their focus and value is on sourcing and vendor selection rather than the capture of the subtleties and complexities of human social interactions and the translation of them into architect-able business constructs (that is the role of the Business Analyst).

The second failing is the development of Trade-Space.  This is the ability to make trade-offs between logical designs.  This is the critical stage before freezing the design for the technical architecture.  This is also vital where soft, social systems such as knowledge, decision making and collaboration are a core requirement.  However, trade-space cannot be affected unless there is some form of quantitative analysis.  The usual outcome is to make trade-offs between technical architectures.   Like magpies, executives and designers, by this stage have already chosen their favourite shiny things.  Energy and reputation has already been invested in various solutions, internal politicking has taken place and the final solution almost eschews all assurance and is pushed through the final stages of governance.

With proper development and assessment of trade-space, companies have the ability to instantiate the complex concepts of front and middle office processes.  Until  now, business analysts have hardly been able to articulate the complicated interactions between senior knowledge workers.   These, however, are far more profitable to outsource other than more mechanical clerical work which is already the subject of existing software solutions.  The higher pay bands and longer setup times for senior information work makes executive decision making the next frontier in outsourcing.

Service offerings

Logical architectures are not usually developed because there is no easy, standardised means of assessing them.  Despite the obvious cost effectiveness logical architectures most Business Analysts do not have the skills to design logical architectures and most Technical Architects move straight to solutions. Logical Architectures which are quantitatively measurable and designed within a standardised methodology have the potential to give large technical service and BPO organisations greater profits and faster times-to-market.

The future is already upon us.  BPO and enterprise services are already highly commoditised.  The margins in outsourcing are already decreasing, especially as cloud-based software becomes more capable.  If high cost labour companies (particularly those in based in Western democracies) are to move to more value-added middle and front office process outsourcing then they will need to use logical architecture methodologies to design more sophisticated offerings.

In the next blog we will show one method of quantitatively assessing logical architectures in order to assess trade-space and make good financial decisions around the choices of technical designs.