Kevin McIsaac

Kevin McIsaac

Read latest work...

Connect with Kevin

Have a specific question for Kevin McIsaac?


Conclusion: Oracle will continue to excel in the Application, Middleware and Database markets, but it also intends to radically transform and simplify IT infrastructure. Oracle’s strategy is to eliminate complexity, create significantly greater business value and reduce infrastructure costs using an Integrated Systems approach. The objective is to enable customers to focus on applications, instead of infrastructure, in the hope they consume more Oracle software.

IT executives should keep abreast of Oracle’s infrastructure innovations, as well as the competitors’, and be prepared to rethink their existing infrastructure approach if an Integrated System can create a significant new opportunity for the business.

Read more

Conclusion: Poor quality and incomplete requirements continue to be a leading cause of IT project failure. While the more widespread use of iterative project management techniques is minimising the impact of bad requirements, it is still not addressing the underlying cause. Accountability for improving the quality of requirements remains elusive. Enterprise architects must take a stronger role in the validation of requirements, and be prepared to intervene when necessary.

Observations: The saying goes that you cannot create a symphony by asking a hundred people to give you ten notes each. This is an apt description of the way requirements may be developed on large IT projects. The result is often a disjointed set of wishful ideas, concepts and assumptive solutions without any intrinsic integrated design or consistent rationale. Given this profoundly flawed starting point, it is not surprising that subsequent project implementation activities that rely on correct and consistent requirements will be inherently challenged.

Challenges in defining requirements: Understanding of the term “requirement” differs among stakeholders. Requirements can be variously perceived as user wish-lists; or detailed product features sets; or complex business process descriptions. The language used to express these requirements is often loose and ambiguous, instead of concise, testable statements of conformance. Requirements often focus on functional behaviour and ignore important non-functional aspects such as performance, security and operational concerns.

Commonly the task of establishing a set of requirements is somewhat blithely described as “requirements gathering” and implies that they already exist ready-formed in perfect shape, and just need to be harvested like simply picking cherries from a tree. Such a perception is a very dangerous attitude – especially among senior executives.

The reality is that high-quality requirements are difficult to create. Unless there is a very clear and concrete understanding of the objectives of the system, and ready access to explicit and accurate supporting information about all relevant dependencies, the process of defining requirements can become a messy and imprecise affair. Common challenges include:

  • conflicting understanding of the underlying business problems between stakeholders

  • limited access to key subject matter experts

  • organisational politics that hinder contribution and create divergent objectives

  • changing circumstances render requirements obsolete

  • time pressures that cause analysis to be incomplete and poorly formed

Dealing with poor quality requirements: Delivery pressures tend to force poor requirements to be accepted unchallenged. In the face of impending (or missed) deadlines, there is acute pressure to have the requirements ‘signed-off’ regardless of the quality. Project governance checkpoints tend to measure when a project milestone has been completed, but not the quality of the actual work products. If requirements are identified as lacking, this advice can be ignored, or dismissed as rework that can occur in later project phases.

The best way to guard against poor quality requirements is to have them validated early and often. Requirements can be quickly tested against some very simple heuristics to gauge the quality and completeness of their definition. Simple tests include:

  • Cohesive – does the requirement address a single, simple business function?

  • Precise – is the requirement completely unambiguous and stated using concise, simple, plain language?

  • Verifiable – can conformance with this requirement be easily proven in the testing phase?

  • Traceable – are all requirements linked back to a clear business need or objective, and are all business needs covered by a comprehensive set of requirements?

The rise of agile delivery techniques has cut the time between requirements definition and requirements testing. This has meant that faulty requirements can be identified faster and at a smaller scale than traditional waterfall techniques. However agile delivery methods are still not pervasively utilised – and very large programs of work found in government and financial sectors still rely heavily on waterfall techniques.

The role of the architect in requirement validation: Requirements elicitation and definition is commonly the domain of the business analyst. Architects tend to be engaged in projects in the earlier conceptual phases to make key decisions about platforms and technologies based on high level business needs. Then, in parallel to the detailed business requirements definition, architects focus on things such as:

  • defining system context and external integration points

  • identifying system components and interactions

  • understanding information structures and flows

  • performance, security and capacity analysis

The risk here is that while the architects are focused on all-things architecture, they remain isolated and disconnected from the detailed requirements definition and validation. But architects are the best placed people to perform requirements validation. They are the experts that should hold the end-to-end system knowledge and enterprise context, coupled with a clear understanding of the business needs and desired benefits to critically and authoritatively validate the quality of requirements.

Despite protestations from architects that requirements validation is unwanted QA of business analyst artefacts, or unnecessary detail, or this is the role of the project manager – architectural validation of detailed requirements must be performed. And project managers must be accountable in ensuring that any deficiencies identified in architectural review are acted upon.

If poor quality requirements are identified by architects, and not addressed by project teams, architects are obligated to escalate the issue for executive attention. Architectural intervention over poor quality requirements is perhaps one of the most important actions that can be taken to improve the chances of project success.

Next steps:

  1. Examine how the quality of requirements is assured on projects within the enterprise.

  2. Check whether architects have appropriate review and oversight of requirement quality, or is this left as a project manager responsibility.

  3. Make architects accountable for requirement validation as a mandated governance checkpoint.

  4. Ensure appropriate escalation path exists for architecture intervention if necessary.


Conclusion Leading IT organisations now recognise that selecting and integrating a mix of best-of-breed servers, storage and networks no longer adds value to their organisation. Instead they are purchasing Integrated Systems from a single vendor that eliminates the cost and complexity of integrating these components; lowers the integration and support risks; and reduces the time to deliver a working solution.

To make this paradigm shift most organisations will need to change the kind of relationship they have with their infrastructure vendors from a purely transactional supplier to a long term strategic partner. For many IT, and vendor staff, this will be a difficult and traumatic transition.

Read more

Conclusion: Enterprise architects must be systems thinkers first and foremost. Enterprise Architecture is a discipline rooted in IT, and its practitioners often have a deep IT background. However as an enterprise architect, an IT heritage can often be a burden as much as it is an advantage. Organisations that are looking for people with the “right stuff” to become an enterprise architect should cast their net wider than just the IT domain.

Read more

Conclusion: The IPv6 day in June attracted significant media attention and raised the profile of IPv6 again. As is typical, the media latched on to the “bad news” and ran headlines stating that the Internet is running out of addresses! While this is correct, most ANZ organisations will not experience any significant impact and the burden of supporting IPv6 will largely fall to the telecommunications vendors, or other organisations that run large public networks.

IT executives need to check that their organisation has a strategy for dealing with IPv6, largely at their gateways systems, and ensure that this strategy does not get blown out of proportion.

Read more

Conclusion: Business architecture is poorly served by IT-centric enterprise architecture teams. While EA teams have the skills to establish detailed technology architecture, they lack the knowledge and understanding of the higher-level business activities that the technology is supporting. Meanwhile business experts who do have an innate understanding of the business landscape lack the skills and tools to create high-fidelity business architecture. To create a complete Enterprise Architecture, organisations should consider splitting responsibility between business and IT areas.

Observations: The terms business architect and business architecture are often used very loosely. In a strict sense business architecture is the subset of an enterprise architecture that deals with the structure and behaviour of organisational assets in support of a business operating model. These organisational assets are generally the non-IT components such as business processes, roles, rules, knowledge, events, locations, services and products.

Most enterprise architecture frameworks (such as TOGAF and Zachman) include the business architecture elements as part of the encompassing enterprise architecture. So in theory, business architects should be members of the enterprise architecture team, just as the information, application and technology architects are.

This is rarely the case.

In IBRS experience, virtually all enterprise architecture teams report to the CIO, normally through another senior IT executive, and exclude important business architecture elements such as business processes, functions, services and products. At the moment many organisations are restructuring IT around a “design, build, run” model and EA is typically positioned in the design stream – alongside areas such as business analysts, business process modellers and usability.

The term “business architect” is a title adopted by people from various areas within an organisation, both inside and outside of IT. These are often senior business analysts, process modellers, strategy areas or transformation consultants, who are outside of the EA group, but use the term “business architect” to indicate a more strategic nature to their work.

The challenge with these self-anointed “business architects” is that while they generally possess immense subject matter expertise and extensive networks with key stakeholders, they lack the structured methodology, or systemic approach to their work which would qualify as an “architectural” approach. They often work at the conceptual or business case level, and are generally unaware of the established discipline for managing business architecture found in enterprise architecture frameworks.

It is important to distinguish between these “business architects” and the function of “business architecture”. IBRS is not aware of any successful formalised “business architecture” teams who exist outside of IT and manage the discovery and definition of business architecture using accepted architecture frameworks and tools that are integrated with the related IT architecture. Business architecture can be found implemented in a number of ways:

  • Some organisations have business architecture functions that operate within EA teams but do so in a limited fashion, and lack the skills and knowledge to craft a complete and accurate picture of the way a business operates.

  • Some have business architecture functions that sit alongside EA teams within IT, but are loosely connected, such as business process modellers, rules analysts or service management functions. The information these teams create and manage is often not integrated with the EA view.

  • Some have business architecture teams that sit in the business but manage information in an unstructured manner in isolation of the IT EA and other groups.

Running business architecture out of the business: Enterprise Architecture has largely emerged from IT and is still often perceived IT-centric activity. But the true scope of Enterprise Architecture is much broader than just the IT elements of an organisation. However given EA has been driven by IT, not surprisingly, most EA teams tend to be much stronger on the technology side of enterprise architecture. The business architecture elements are often ignored, or pushed out to separate teams, such as business process modelling or business rules. Rarely are all the business architecture elements managed with the same care and attention as the technology and application areas.

Ideally a business architecture team would sit in a business area, report to a business executive and manage business architecture elements using an established framework and information repository that is shared with (and protected from) their IT architecture colleagues. They would have a separate governance process that is accountable to a single board level executive. They would act in close concert with IT architecture but be logically separated. In these situations the role of an EA framework clearly delineating between what is business architecture and what is IT architecture and how they relate is essential.

The diagram below shows how the enterprise architecture function could be split along business and technology lines.

In this situation the interface between business architecture and technology is tightly coupled around applications and information. The governance mechanisms of business architecture and EA would need to be carefully synchronised around these dependencies. A set of principles would need to be established and agreed between the EA and business architecture governance bodies to promote coordination and cooperation. An organisation with a low governance maturity would struggle to implement such a structure effectively.

The diagram below indicates a generic governance structure that could support the operation of a dual business / IT enterprise architecture strategy.

Key to this structure working is ensuring that the information managed by the business and IT areas is unified in a single repository with consistent architectural principles and modelling standards applied across the two areas. The responsible senior business executive must have an appreciation for a systemic approach to business architecture and recognise the importance of the activity as a management discipline.

Next Steps:

  1. Understand whether the Enterprise Architecture team is effectively supporting the business architecture view. To do this have business stakeholders validate selected models of business functions, services or processes. Decide whether they are an accurate and meaningful representation of the business operating model.

  2. If not, consider whether situating the responsibility for business architecture under a business executive would enhance the completeness and accuracy of the enterprise architecture. For this to be successful ensure the following pre-conditions are met:

    1. A mature governance culture exists within the enterprise

    2. A responsible senior business executive is willing to take on the function, understands the value, and appreciates the nature of a structured, systemic approach to architecture definition and management of business activities

    3. A unified set of information management tools is available to support the business and IT architecture teams in establishing and maintaining the enterprise architecture

    4. Most critically, a business unit exists that has a purview across the entire organisation and does not form part of a siloed operation. If this is not the case, then the best place for EA is in IT.

  3. Understand the transition plan for enabling business driven Enterprise Architecture

    1. Initially groom business architects inside the EA team

    2. Next establish a dotted reporting line from the EA team to the nominated business executive

    3. Finally transition business architecture as a separate function to the new arrangements


Conclusion: VMware’s vSphere Storage Appliance (VSA) is the beginning of the end of the modular storage market. While built for the low end of the market, the VSA will scale-up over time and disrupt the modular storage market. The key benefits of the VSA in a VMware cluster are: lower infrastructure complexity, lower capital costs, greater workload agility and reduced IT skills.

SMBs should consider the VSA at their next major infrastructure refresh. Enterprises should experiment with a standalone environment, such as dev/test or a new departmental application, and become familiar with this technology. Enterprise should then create an adoption strategy to replace modular storage in their VMware server cluster as the VSA matures and scales up.

Read more

Conclusion: An effective Enterprise Architecture should enable the strategy of an organisation to be clearly linked to the underlying business processes and information technology assets. Established enterprise architecture frameworks such as Zachman, TOGAF et al. include limited support for modelling the strategy of an organisation. An emerging framework, the Business Motivation Model, provides a much richer structure for capturing an organisation’s objective. Focusing on the strategy of an organisation represents an opportunity for Enterprise Architects to engage with the highest level of organisational planning and reflect true business intent, rather than reverting to a limited techno-centric perspective.

Observations: The Open Management Group defines “business architecture” as:

"A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands."

Enterprise Architects have long been comfortable managing the raw technology assets (applications, infrastructure, information etc.) that support the “tactical demands” of system design required to support enterprise change. IBRS’ experience has also shown that many organisations in Australia are making great progress in mapping business processes and services into an integrated architecture picture. The challenge is now connecting the knowledge of business processes and business rules to the higher-level strategic objectives that govern organisational evolution.

The first prerequisite in linking architecture to strategy is that an organisation has agreed and defined a strategy that clearly articulates its mission and purpose. There are many challenges in doing so. Sometimes organisations struggle to agree on their core purpose; neglect strategic planning activities; or maintain the strategy in tacit form without ever formally documenting it. An organisation may have a valid strategy defined, but the Enterprise Architecture team may not be appreciative of it.

In the absence of a defined strategy, Enterprise Architecture development can be a compelling voice calling for the establishment of a defined strategy, or indeed even leading the charge in its creation. However, beware the political risks attached to launching into this debate. Questioning or challenging an organisation’s strategy (or absence thereof) can be a confronting experience and risks adverse reactions from important stakeholders who have not bought into the concept.

Assuming a strategy has been identified and agreed there needs to be a way for it to be expressed architecturally. Popular Enterprise Architecture frameworks usually have some capability to capture important strategy elements. For example:

  • The Zachman framework includes what it calls the “motivation description” as one of the core six dimensions of its taxonomy

  • The TOGAF 9.0 framework optionally includes business drivers, goals and objectives in the “Motivation Extensions” of the core meta-model

  • The Australian Government Architecture 2.0 defines the “Mission and Business Results” area of the Performance Reference Model which maps to the strategic outcomes and outputs defined by the government for public service agencies

For organisations which have not yet embraced an Enterprise Architecture framework there is support available in frameworks such as the Open Management Group’s Business Motivation Model1 (BMM). In essence the BMM is a formal model for depicting business plans. However the BMM is not currently well known within the enterprise architecture field so it is worth examining in more detail.

The BMM is a structure that supports understanding the ‘doing’ of an organisation (mission, strategy, tactics) alongside the ‘being’ (vision, goals, objectives). The BMM situates the means (“doing”) and end (“being”) in the context of the forces or “influencers” that could impact on to either the means or the ends. Related to the “influencers” are the “assessments” of the potential impacts of the influencers and the mitigation approaches to deal with them.

These “means”, “ends” and “influencers” are then linked to the responsible organisational units and business processes. These responsible elements should already be defined in an Enterprise Architecture model, or business architecture view and are not directly part of the BMM itself. The operation of the organisational units and business processes are governed by “directives” that specify the business policies and rules that apply to the “means” in pursuit of the “ends”.

The BMM provides a much richer level of detail than the established mainstream Enterprise Architecture frameworks for documenting a strategy – delving into business policies, impact assessments, assets, liabilities and so on. This richer level of detail facilitates the modelling of a high-fidelity business plan (or strategy) if so desired. For large organisations the BMM model can reflect a nested approach where each organisation unit can generate a BMM model that can link to the superior or subordinate BMM models as appropriate.

The linkage between BMM elements and underlying technology architecture is through the associated business processes and rules. The linkages to business processes and rules once defined in the BMM can be mapped back to the supporting systems and applications. This establishes the linkages from business aspirations through to technology implementation.

It is worth noting that the BMM is methodology neutral. It describes the information to be managed, but not how the information should be gathered. In practice maintenance of a BMM or any Enterprise Architecture framework strategy model should be done in lock-step with the strategic planning decision-making cycle of an organisation.

Ultimately the value of maintaining an organisation strategy as an architectural model (EA framework, BMM or otherwise) provides a number of key benefits:

  • an organisation’s strategy can be made explicit and the rationale behind changes to it become visible and shareable

  • the outcomes of strategic decisions can be traced to the operational impacts across systems and services


Next steps:

  1. Understand the how the organisations strategy is defined – is it well formed and formally documented?

    • If a written strategy exists have the Enterprise Architecture team document the strategy within either established EA frameworks or adopt an offering like the BMM for that purpose.

    • If not, advocate for better clarity and rigour around organisational strategy.

  2. Make the incorporation of the strategy into the enterprise architecture pass the executive “so what?” test.

    • Apply it to real life examples to increase understanding or clarify decision making for a particular important issue.

  3. Embed the maintenance of the architecture view into the strategic planning lifecycle for the organisation.




Conclusion: With most organisations now completely dependent on IT systems for their day-to-day operations, and ongoing viability, ensuring the availability and recoverability of these systems is one of the IT organisation’s most important responsibilities. However, like many other forms of insurance, disaster recovery planning is not seen to be urgent by IT or the business, and often fails to meet the requirements of the business.

IT executives need to look for the early warning signs that their disaster recovery plan is compromised, and if found, take action to defuse this ticking time-bomb that could blow up their career.

Read more

Conclusion: Business process management and enterprise collaboration tools are converging into a new form of enterprise capability termed Social BPM. This new approach harnesses the viral power of social networking into enabling real-time user-developed collaborative business processes within the enterprise. This convergence may deliver the transformational value promised, but never realised, by either technology in isolation. Organisations should watch this trend carefully and have a combined strategy for enterprise collaboration and business process management to be in a position to exploit the amplified value that social BPM promises.

Observations: Business process management and enterprise collaboration have long been two prominent themes for organisations seeking to improve efficiency and productivity through IT innovation. IBRS experience with Australian and New Zealand organisations has found the return from investments into these areas to be underwhelming.

Business process management has tended to focus on centralised business process modelling and attempts at process re-engineering. There are many challenges in doing this. The common model has been for a team of dedicated business process modellers to study the organisation from an almost anthropological perspective, capturing imperfect business processes from the field and seeking to create an optimised future state. However, the resulting models are often ineffectual in driving real change in the organisation, succumbing to the ivory tower syndrome of being disconnected from the “real world”.

At the same time enterprise collaboration and more recently enterprise social networks have been seen as a way of improving communication and interaction within the enterprise. Generally this has meant the implementation of browser-based content and document management systems, along with the ubiquitous (and often token) “blogs and wikis”. While centralised, well-structured searchable corporate knowledge is a tremendous asset, it tends to reflect static policy and operational documentation, not real-time system and stakeholder behaviour.

The over-trumpeted “Web 2.0” technologies do provide a degree of democratisation of content and freshness of information but are most commonly seen at the periphery of core business activities. Social networking tools are emerging within the enterprise but the enduring business value of “James just made a cheese toastie in the marketing kitchen” status updates are viewed with scepticism.

Social business process management. A new class of information management tools is emerging. These web-based tools allow business processes to be defined and implemented in a decentralised fashion using “Facebook-style” social networking tools. These tools leverage the creativity and intelligence of human participants in work processes to deliver productivity and efficiency benefits. The fundamental shift in perspective is to acknowledge that a business process is a fluid activity performed by a group of people acting co-operatively, rather than a rigid set of flowcharts imposed by an aloof systems bureaucracy.

With social BPM the participants in a business process are responsible for defining it. Once a business process is operational, the participants can use an array of social technologies including social networking, status updates and comments, RSS/twitter feeds, blogs/wikis to augment the process with contextualised support. Supporting IT systems feed important updates into the social stream to provide events that can trigger support from the underlying network of interested parties.

This is a novel concept and an example will help illustrate how it works in practice.

A fictitious manufacturing company has a range of people supporting the enquiry-to-sale business process. With a social BPM tool, a stream of relevant events underpinning the business process is made available to users. A range of people in the company may have subscribed to receive events from a particular customer. These events are notified across web, mobile and email channels. In the web channel these updates may appear in a similar fashion to a Facebook page.

  • An event is posted from the CRM system indicating a particular customer’s contract will expire in two weeks.

  • A comment is left by a salesperson saying he is planning to visit them next week and will organise a renewal.

  • Another comment from a legal person provides a link to the new contract template that must be used for future transactions.

  • An engineer posts a comment that they have an active support call open which needs to be finalised if they choose not to review the contract.

  • A salesman who has been assigned to a different account chooses not to be notified about this customer and removes them from his subscription feed.

  • After the contract is renewed the SAP system posts an automatic hyperlink to the invoice which was generated for this client.

  • A marketing expert notes that this process could be improved by having a customer satisfaction report being completed for each contract renewal and modifies the defined business process to automatically post a link to the client satisfaction survey system after each renewal for a client is completed.

This example shows have a user-driven real-time business process emerges that uses collaboration technologies across a variety of channels to improve productivity, increase quality and improve client service. Key to this process is the feeding of events from both human and system participants in the process. It is the integration of important system events into the social media stream that distinguishes Social BPM from the established enterprise collaboration or unified communications models.

While a number of CRM and ERP systems may offer social features, these are often limited to within the confines of a particular software system and cannot span across the enterprise. Vendors of broad-spectrum social BPM tools include Appian Tempo, Salesforce Chatter, IBM Blueworks Live, Oracle BPM Suite 11g and PegaSystems.

Social BPM embeds the responsibility and power for business process design and management into the hands of the people responsible for delivering in the real world. It also connects the raft of collaboration tools directly into the nervous system of business process execution. While this devolved model of organisational management may run counter to the traditional command-and-control mentality of some large organisations, it opens up a new model for democratic empowerment of business users.

Next Steps:

  1. Take stock of the value gained from enterprise collaboration and/or business process management investments within the organisation – are real benefits being realised from these investments?

  2. Conduct a trial of a social BPM tool within the organisation with a passionate and curious user base. With a web-based SaaS social BPM tool this can be achieved at little cost, risk or commitment. The user driven philosophy also means this can be achieved with little corporate support.

  3. Evaluate the findings of social BPM usage against traditional methods. Decide whether it suits the culture of the organisation and is sustainable as a long-term business platform. If so reframe the business process management and enterprise collaboration strategy to embrace social BPM as a core strategic objective.

  4. Ensure appropriate governance, risk and policy controls are in place to guide social BPM as a platform for business execution.


Conclusion: Most branch office data is poorly protected by the organisation’s existing backup strategy. Recent improvements in network connectivity, and the commoditisation of advanced deduplication techniques, fundamentally change the landscape and make highly automated, reliable and cost effective branch office affordable to most organisations.

Organisations with extensive branch office data that is not adequately protected should revaluate their branch office backup strategy.

Read more

Conclusion: Business intelligence has traditionally served as an after-the-fact reporting and analysis capability that drifts weeks or months behind current events. Modern enterprises demand timelier access to integrated information. This demand cannot be met by conventional business intelligence approaches and requires a variety of new techniques targeted at the immediacy of the information required.

Read more

Conclusion: Oracle’s decision to end all further development on Itanium, will force HP Integrity customers to make a strategic decision between Oracle and Itanium. Providing the latest version of Oracle software is used customers have until 2016 to implement this decision. Since Red Hat and Microsoft have also abandoned Itanium, IT Organisations must evaluate the long-term viability of this architecture based on its ability to run the applications that matter to the business.

Since high-end UNIX systems typically have a 7-8 year lifespan, Organisations must have a strategy before purchasing new systems or undertaking a major upgrade. This strategy will be driven by the degree of dependence on, and satisfaction with, Oracle’s business applications.

Read more

Conclusion: Between the initial enthusiasm of planning a new system, the focused effort of selecting a vendor and negotiating a contract, and the frenetic activity of implementation, nobody wants to think about how to deal with the possibility of a major project failure. While rare, organisations need to put in place contingency plans before they start, preferably during planning and negotiations.

Organisations should establish a framework for dealing with failing systems that gives them the necessary tools to quickly get it back on track or terminate it and seek reparation if appropriate. Without this, organisations risk a long and bitter struggle, which is both costly and embarrassing to themselves and the vendor.

Read more