Architecture Owned Code

Much has been made of the rift between agile developers and IT architects, especially enterprise architects.  Agile development has turned the solution implementation world on its head, eschewing traditional architecture and all other attempts to define things in advance.  But the agile world has evolved to the point where an architectural foundation is recognized as necessary to implement agile on a large scale.  Without architecture to hold things together, you may well have a dozen agile teams moving in completely divergent directions – rather than building a cohesive product.  But this doesn’t take us back to the world of big design up front (BDUF) – architecture has to evolve as well.  The key is to develop the architecture in parallel with the agile development.  Very much like agile planning (where you create a high level plan, but only produce detailed plans for the next increments – on a rolling basis), agile architecture starts with a high level superstructure and detail is added as needed to support the agile teams.  Architecture decisions are pushed down and deferred until as late as possible – so that refactoring is minimized when decisions are modified.

In years past, architecture provided guidelines and directives (often in the form of a reference architecture) and developers either complied or they didn’t.  Governance was applied after the fact – certifying that a product was in compliance with the architecture (what a surprise – it almost always was!).  This, of course, led to architectural anarchy and situations where organizations found that they had more than one of everything (from platforms to coding styles) and many of some things (security implementations, for example).  This situation of maintaining multiple platforms, redundant applications, and poorly documented code has led to the high percentage of the IT budget being devoted to O&M, rather than new development to address new business requirements. 

So, what does this have to do with Architecture Owned Code (AOC), you might ask?  Well, at Everware-CBDI we have developed an approach that supports agile development at scale.  A component of the approach takes all of the aspects that you want to have consistent across the enterprise (such as deployment details, authentication, error handling, auditing, data access, messaging, common business APIs, etc.), creates models to capture these aspects and other design patterns to be applied across the board, and generates the code for this “common platform” that is  provided to the development teams to build upon. While this may include many low-level, utility services, it can also include access to common business services and COTS APIs, such as for credit processing or document management. Providing AOC automates governance and flips the perception of architecture as an inhibitor of development to an enabler of development.  We have found that most development teams accept this readily, because it lets them focus on solving the business problem rather than being blocked by wrestling with the intricacies of the technical platform.  The AOC base grows and is refactored as required by parallel agile architecture development teams. 

The result is that development proceeds much faster because the agile teams are able to leverage this common Enterprise-specific platform in much the same way they leverage provided APIs in many current products, frameworks and languages.  This approach has many other benefits as well.  For instance, the AOC is of higher quality than hand-produced code, is consistent across all development teams, and is able to more easily be modified or refactored.  As a result, the tendency of the code base to become more brittle as it grows is fundamentally reduced.  In addition, the refactoring exercises can be essentially invisible to the agile developers – performed in an architecture sprint, regenerated, and provided to the teams.   

Architecture Owned Code has the potential to revolutionize application development and fully enable agile development – at the enterprise scale.  To learn more about this new approach, please contact us.

Organizational SOA

Anybody recently tell you that SOA is an IT integration technology? Don’t believe it. SOA’s biggest selling point is agility, and you don’t get that from an integration technology. SOA is actually architecture.

Forget IT. SOA can be applied to an organization (even one devoid of IT). If we throw out the conventional definition of organizations of hierarchies and functional units and replace it with a framework of business units offering services, we can derive a service oriented organization. Starting with the products and services we provide to external parties (external customers) and the products and services we obtain from external parties (external suppliers), we have the beginning of a framework to describe the organization. If we then add sets of internal customers and suppliers and define the act of providing a product or service to a customer as a service, we have the next step – a collection of services – tasks performed for a consumer. We can then map the incoming products and services to outgoing products and services by defining processes that consist of steps in transforming inputs to outputs. The processes and steps in the process are the services previously defined. So, processes become a string of services that are orchestrated to produce outputs. Now services are a lot like processes (very fractal) with inputs, activities and outputs; and, they can consume other services, so we need some rules to prevent service conflicts and circularities. This is achieved by defining an architecture of services with layers dividing the services based on rules about which services can call which other ones (for example, a typical rule is services at a given layer cannot call services at a higher layer).

Organizations that define themselves as collections of service (org) units, achieve agility from two basic facts: (1) processes can be changed by rearranging the services or replacing a given service with a different (new?) service and (2) new products can be produced by combining existing services in new ways and adding a few additional ones. Think about an insurance company offering a new coverage product – many of the activities required are the same as for existing products and can be reused.

In IT, the concepts are the same, except that now we are talking about software components instead of organizational units and they are even more flexible – software services can be offered to multiple consumers from the same distributed component on the network (i.e., the “cloud”). All of this adds up to a significant gain in agility both on the organizational and the IT side.