One of the hardest concepts to get people to agree on in the business world is the definition of Enterprise Architecture (EA). Gartner defines EA as “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.” They take this a step further saying that EA “delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business outcomes.”
From our experience, enterprise architects typically fall into one of two camps. Either they think of EA as a business-centric discipline, aimed at better aligning IT capabilities and investments with business priorities (in which case they more than likely subscribe to the notion of following an industry standard EA framework, such as Zachman or TOGAF). Or they think of EA as a technology framework, and as such often correlate the “enterprise architecture” with the deployment of one or more enterprise platforms, such as Oracle or an open source framework, etc.
Here, we will refer to EA as the collection of enterprise models that represent four inter-related perspectives – Business, Application, Information and Technology. These models are used to guide the development and optimization of business capabilities and solutions, in line with an organization’s strategic priorities. The foundation of these models is a bedrock of information about the enterprise – business and IT applications, organizational capabilities, objectives and strategies, data assets, technologies, infrastructure and projects. It is the integration of these data points and the dependencies between them that define the very DNA of any organization. By understanding and visualizing the current DNA or make up of the enterprise – or some aspect thereof – we can begin to identify and implement the changes that need to be made to produce new and better results.
Despite the high value “knowledge” and insight captured by EA, there is one aspect of IT portfolio baselining that EA tends to overlook. We often say that EA is a set of blueprints that represent how the business operates and is aligned. We commonly refer to this as the “boxes and lines” that make up the organization. But what about looking inside the box? Specifically assessing the health, size, structure and quality of the software that make up the applications that drive businesses? This has become known as Software Intelligence.
Software Intelligence is just that – insight into complex software structure. It includes software health, software size, software flaws and software blueprints. It also includes software benchmarks – comparative analytics of the above by industry and geography. Let’s break this down a little further and explore what this ‘inside the box’ view does for the discipline of Enterprise Architecture:
1. Software Health
Software Health is a measure of a) the robustness of an application, or the risk of critical failures in production, b) efficiency – the risk of performance or scaling issues, c) security, i.e. the risk of security breaches in an application, d) changeability, a measure of the ease of adding new features and fixes, and e) transferability, a measure of the ease of knowledge transfer or change of ownership. These five dimensions make up the overall health of an application. When integrated with EA it provides a whole new perspective to look at the portfolio. Most EA deliverables look at applications from a business use standpoint, but this is often not enough to make critical decisions, like moving to the cloud, repair vs. replace, etc. By determining the true health of the software – based on the actual source code itself – enterprise architects can provide much more meaningful guidance on strategic IT initiatives.
2. Software Size
Software Size is also a critical aspect of Software Intelligence that has two dimensions. The technical size – in terms of the sheer number of lines of code and technical component complexity – and functional size, which is based on the industry standard function point analysis method. By determining the true technical and functional size of an application, enterprise architects can provide more meaningful weights and scales to their recommendations, again, based on the truth in the code.
3. Software Blueprinting
The final aspect of Software Intelligence is software blueprinting. As mentioned above, a core tenet of EA is blueprinting, but they tend to be enterprise blueprints – high level dependencies, work flows, etc. The “inside the box” application blueprints are difficult and time consuming to maintain. In most organizations we work with, they tend to be inconsistent in context, level of granularity and representation, if they exist at all. And those that do are typically outdated. Software Intelligence – based on the actual source code – provides visibility into the inner-structure of software and transaction flows. The integration of these software blueprints with EA is the very means by which enterprise architects can connect and collaborate with solution architects. It is the bridge that connects the ‘physical world’ of software design with the conceptual world of enterprise architecture, offering invaluable new insights.
Consider these things. In many cases, when software fails, businesses fail. Security breaches can ruin an organization. And most devastating security failures are not the result of perimeter breaches, they are the result of core, structural software flaws. If you’re moving to the cloud, what are you moving to the cloud? Software. Is your strategic agenda to become a ‘data-driven enterprise’? What captures, processes, persists, presents, and protects all that data? Software. Is your IT development and maintenance outsourced? Off shore? What are those third-party providers delivering? Software.
Fact is, we live in a software-driven world. For EA to live up to the promise of guiding the development and optimization of business capabilities and solutions, it must begin to look “inside the black box” of software. And to do that it requires Software Intelligence.
[Suggested reading : How to implement Design Pattern – Separation of concerns]