Let me preface this posting with one important caveat: This was written from the perspective of having spent several years working within a very large multi-national software development effort, within a highly regulated industry, with over 150+ developers, across multiple large-scale enterprise application domains, integrating with many different externally contracted service providers - as well as dozens of internal applications (bespoke systems, as well as heavily customized COTS packaged software)
The buzz-trend headlines of today's pundits assume we should move toward a Point-to-Point API strategy for integrations both within and without the enterprise.
An oft repeated line of argument that arises when pundits relish their prognostications of the death-knell of Service Oriented Architecture (SOA), revolves around the notion that the world-wide-web doesn't have a centralized service bus - and therefore, by inference, any corporation that has the temerity to think that they might need to provision an Enterprise Service Bus (ESB) - is implementing something that is foolishly wasteful, extremely heavy-weight, and probably overkill.
This argument is probably quite right in many cases.
However, within any enterprise-level organizations of appreciable size - with many different applications disbursed across the organization (both politically and geographically) - there are common and recurring application infrastructure capabilities that will end up being re-implemented again-and-again within the endpoints of any Point-to-Point integration strategy, if there isn't some enterprise-class service bus capability established.
For example, does it make sense for every individual application to implement their own approach to:
- retry logic for guaranteed delivery
- exception handling
- monitoring/reporting/alerting
- caching
- fail-over routing
- implementing fan-in and fan-out patterns, with the inherent brittle dependency of canonical
mapping to each up-or-down stream application
- managed file transfers
- job scheduling
- data encryption (at-rest, and in-motion)
- complex event processing
- message queue management
The outcome of an absence of any enterprise service bus capability, cannot help but result in some trade-off decisions that have significant negative consequences for long-term maintenance, organizational agility, and software development costs.
Integration strategies within many large-scale enterprise organizations must often adhere to a much higher threshold of rigor (such as audit traceability and monitoring) - and Point-to-Point integration strategies often result in duplication of code in places that could be more centralized maintained, managed, and provisioned via a service bus (note: I'm not saying One ESB to Rule Them All - an ESB might be logical, virtual, distributed, and quite often federated).
I'm not saying Point-to-Point is a necessarily a bad integration strategy in all cases, or that an ESB is a necessary component of an enterprise-class integration strategy. But to ignore the concerns raised above, or to burden application architectures with what should be common and reusable enterprise-level shared infrastructure-like capabilities - that results in the re-implementation and redundant maintenance of such common functionality - is something that should be questioned, and strongly challenged.
The challenge/questioning of whether there is a need for Enterprise Governance is another aspect of this discussion that is often dismissed as a needless overhead to the software development process. In my experience, this is most often argued most passionately by folks who have taken the idea of Agile to an unhealthy extreme - and who seem to use it as a justification for their genetic lack of enthusiasm for documenting their work. However, within any highly regulated industry, Enterprise Governance certainly has a proper and necessary place. The trick is to do it with the lightest touch possible. Without Enterprise Governance, without a guiding vision that has continuity (i.e. from a permanent Enterprise Architecture team) beyond the typically high turn-over of all-too-often mostly outsourced development teams - development can become a Wild West, decision making is almost invariably short-sighted, tactical, and representative of silo thinking - without any broader / longer term strategic thinking evident -and becomes a function of the strongest personalities on a development team (at best) - and (at worst) without any cross-application team communications of decisions, tools selection is made within a vacuum...devoid of any guidance from policies, standards, or specifications.
Some possible signs that your Enterprise Governance process may be out of control:
- You have more than [z] developers on staff, and you have no Enterprise Governance process, where [z] is greater than the size of a small garage start-up.
- You have no Policies, Standards, or Specifications established to guide your development teams.
- Your governance process stipulates the creation of [n]X additional artifacts than your design/development process produces.
- Your governance process stipulates [y]X more review checkpoints than performed in your design/development process.
- One or more of your developers has stated the following: "The code is the {design|documentation}"
- One or more of your developers has stated the following; "We don't need to write unit tests"
- Your code base has a high cyclomatic complexity rating
- Your design/development process does not include frequent peer reviews.
- You have no visibility into code metrics
- You don't have an automated Continuous Integration build process established
- You are not running static code anlaysis tools during your Continuous Integration build process.
- You have no reserve capacity in your development group to review and address the technical debt that is accumulating (as found by various static code analysis tools, e.g. Sonar task executed by Jenkins/Hudson)
