Separation of Concerns and Agile Development

The Latest Trend in Mobile LocalizationThe Latest Trend in Mobile LocalizationThe Latest Trend in Mobile LocalizationThe Latest Trend in Mobile Localization.

The role of governance is to define the decision rights of the participants in the organization – IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School Press.

When small teams of individuals take the Agile Manifesto literally and apply it to the business of writing software for money, those decision rights of the organization are usurped, sometimes without the formal organization realizing what is happening.

Let’s look a little closer at a large corporation that is writing internal software for its operations. Or writing software for sale to others, who will use the software for their internal operational purposes.

For the internal software systems, the user makes the assumption that the software works according to the needed capabilities of the organization. This usually means that the business can conduct its operational processes without consideration of the state of the software. Running your retail inventory control system for 147 warehouses around the United States is not going to be successful with a Beta version of the software. Or a version of the software that is emerging in its capabilities on a weekly basis. How to develop and deploy such a system is another topic, an important topic for another blog, but the operational aspects – what is needed, when it is needed, the order of the needed capabilities – of the deployed system are defined by the Users of the system, not the developers of the system. In this governance paradigm, the Product Roadmap and Release Plan define these outcomes, connected to the business strategy used to fund the development – all using the 12 Agile principles.

So how does a production grade application get into production. First, let’s look at the IT Operations structure of a production-grade system and the motivations for seperating the concerns for the development of the system. Non-functional concerns such as time and space predictability, dependability, safety, and more recently security, have an increasingly large incidence on system development in high-integrity application domains [1]

Data is separate from the application that use the data. The classic systems in the 1970’s had the data access and many times the data itself embedded in the application. COBOL programs use IMS databases, but access to that data is only available when the COBOL program is running. This is the motivation for separate the data into a Database (Oracle, SQLServer). So it is not to the advantage of the corporation to have the management of that data be spread across teams of developers. The data belongs to the corporation, not the development teams. To do this we need Data Based Administrators to manage this corporate asset.

In large-scale IT systems, the architecture of the system is many times defined by a vendor. SAP, Microsoft Dynamics, and other ERP systems. The architecture of these systems is defined by the vendor. Here are a few words on this topic for a domain I worked in”