On the Brink of Structure and Chaos: Framework Prescription and Real-World Flexibility

An often returning discussion with my clients is the practical applicability, boundaries, and presumptions of enterprise architecture (EA) frameworks. Following a recent debate on LinkedIn, some EA practitioners suggest that dynamic systems models, such as Stafford Beer’s Viable Systems Model (VSM) (Beer, 1994) , should actually replace existing prescriptive framework practices. In my own thesis (Jensen, 2010), I furthermore discuss the options of integrating cybernetic and second order systemic models in enterprise architecture planning and management on the basis of a thorough analysis of Australian government EA and SOA practice.

However, in this debate, it is important not to frame systems thinking as the silver bullet, which can magically and immediately fix all problems of management practice, be it process management or government architecture planning. Systemic thinking in itself may, actually, be overly prescriptive through reductionist assertions of how organisations function, e.g. through the claim: “organisations are systems” as opposed to “organisations behave as systems in particular situations.” Assuming that the world consists of systems as an ontological pre-given only paves the way for yet another prescriptive theory.

I usually tell my clients that there are two key observations around healthy framework and methodology practice. This basically boils down to admitting the following two claims:
  1. Best practice frameworks and reference models provide a great starting point and rational structure for beginning an architecture endeavour. Obviously, you don’t need to reinvent the wheel, and the frameworks provide a common language and conceptual platform for sharing ideas and implementing projects. Any good framework provides the tools, templates, and management structure for relatively quickly deploying the skeleton of an architecture practice. Prescription gives guidance, direction, and shared understanding of EA purpose and planning.
  2. However, prescription may also heavily limit the creativity and flexibility of rapid transformation projects. EA is often put in place in order to rapidly change the organisation for the better — or what Hjort-Madsen (2008) calls architecting for better outcomes. If the method is too inflexible or does not allow people to make shortcuts and rapid improvements for the better, it is a sign of too heavy prescription. Architecture turns into a handicap as opposed to providing a viable management reporting function. Architecture has transformed into a heavy-weight documentation exercise producing massive stacks of documents that nobody will ever return to again.
Good framework practice comes from finding the right balance between structure and flexibility. The framework must guide, direct, and support the architects at work so they can share and reuse where possible. On the other hand, the framework should promote and highlight the appropriate degree of managerial buffer in order to easily overcome problems and churn out creative solutions as opposed to locking down framework users by applying layers of managerial review and approval bureaucracy for the sake of (often unnecessary) traceability. As my thesis research indicates, an Australian state government agency chose to temporarily ignore their EA modelling and documentation framework whilst transitioning from current to future state.  Technological, political, and managerial changes occurred so often that the existing reference framework was simply too prescriptive. After reaching a point of reasonable stability in terms of business requirements and change in demand, it was then feasible to return to the structural stability and rigour of the framework.

My key message is therefore: be careful when implementing your architecture practice in your organisation. Your people need structure and guidance but also flexibility and buffer for overcoming changes rapidly in an elegant fashion.

Beer, S. (1994). Brain of the Firm (Classic Beer Series). Wiley.

Hjort-Madsen, K. (2009), Architecting Government: Understanding Enterprise Architecture

Adoption in the Public Sector, Phd doctorate.

Enterprise Architecture as Business Capabilities Architecture

"Why do enterprise systems like SAP fail in some companies yet succeed in others? Clearly, the interrelationship between technology and process, skills and culture was not taken into account." Dana Bredmeyer in Enterprise Architecture as Business Capabilities Architecture http://www.bredemeyer.com/pdf_files/Presentations/EnterpriseArchitectureAsCapabilitiesArchSlides.PDF

I’ve posted this

Creation of a strategy for the consumption and management of Cloud Services in the TOGAF Preliminary Phase

In a previous article I described the need to define a strategy as an additional step in the TOGAF 9 Preliminary Phase. This article describes in more details what could be the content of such a document, what are the governance activities related to the Consumption and Management of Cloud Services.

image

Before deciding to switch over to Cloud Computing, companies should first fully understand the concepts and implications of an internal IT investment or buying this as a service. There are different approaches which may have to be considered from an enterprise level when Cloud computing is considered: Public Cloud vs Private Clouds vs Hybrid Clouds. Despite the fact that many people already know what the differences are, below some summary of the various models

· A public Cloud is one in which the consumer of Cloud services and the provider of cloud services exist in separate enterprises. The ownership of the assets used to deliver cloud services remains with the provider

· A private Cloud is one in which both the consumer of Cloud services and the provider of those services exist within the same enterprise. The ownership of the Cloud assets resides within the same enterprise providing and consuming cloud services. It is really a description of a highly virtualized, on-premise data center that is behaving as if it were that of a public cloud provider

· A hybrid Cloud combines multiple elements of public and private cloud, including any combination of providers and consumers

image

Once the major Business stakeholders understand the concepts, some initial decisions may have to be documented and included in that document. The same may also apply to the various Cloud Computing categorisations such as diagrammed below:

image

The categories the enterprise may be interested in related to existing problems can already be included as a section in that document.

Quality Management

There is need of a system for evaluating performance, whether in the delivery of Cloud services or the quality of products provided to consumers, or customers. This may include:

· A test planning and a test asset management from Business requirements to defects

· A Project governance and release decisions based on some standards such as Prince 2/PMI and ITIL

· A Data quality control (all data uploaded to a Cloud computing service provider must ensure it fits the requirements of the provider). This should be detailed and provided by the provider

· Detailed and documented Business Processes as defined in ISO 9001:

o Systematically defining the activities necessary to obtain a desired result

o Establishing clear responsibility and accountability for managing key activities

o Analyzing and measuring of the capability of key activities

o Identifying the interfaces of key activities within and between the functions of the organization

o Focusing on the factors such as resources, methods, and materials that will improve key activities of the organization

o Evaluating risks, consequences and impacts of activities on customers, suppliers and other interested parties

Security Management

This would address and document specific topics such as:

· Eliminating the need to constantly reconfigure static security infrastructure for a dynamic computing environment

· Define how services are able to securely connect and reliably communicate with internal IT services and other public services

· Penetration security checks

· How a Security Management/System Management/Network Management teams monitor that security and the availability

Semantic Management

The amount of unstructured electronic information in enterprise environments is growing rapidly. Business people have to collaboratively realise the reconciliation of their heterogeneous metadata and consequently the application of the derived business semantic patterns to establish alignment between the underlying data structures. The way this will be handled may also be included.

IT Service Management (ITIL)

IT Service Management or IT Operations teams will have to address many new challenges due to the Cloud. This will need to be addressed for some specific processes such as:

· Incident Management

o The Cloud provider must ensure that all outages or exceptions to normal operations are resolved as quickly as possible while capturing all of the details for the actions that were taken and are communicated to the customer.

· Change Management

o Strict change management practices must be adhered to and all changes implemented during approved maintenance windows must be tracked, monitored, and validated.

· Configuration Management (Service Asset and…)

o Companies who have a CMDB must provide this to the Cloud providers with detailed descriptions of the relationships between configuration items (CI)

o CI relationships empowers change and incident managers need to determine that a modification to one service may impact several other related services and the components of those services

o This provides more visibility into the Cloud environment, allowing consumers and providers to make more informed decisions not only when preparing for a change but also when diagnosing incidents and problems

· Problem Management

o The Cloud provider needs to identify the root cause analysis in case or problems

image

· Service Level Management

o Service Level Agreements (or Underpinning contracts) must be transparent and accessible to the end users. The business representatives should be negotiating these agreements. They will need to effectively negotiate commercial, technical, and legal terms. It will be important to establish these concrete, measurable Service Level Agreements (SLAs) without these and an effective means for verifying compliance, the damage from poor service levels will only be exacerbated

· Vendors Management

o Relationship between a vendor and their customers changes

o Contractual arrangements

· Capacity Management and Availability Management

o Reporting on performance

Other activities must be documented such as:

Monitoring

· Monitoring will be a very important activity and should be described in the Strategy document. The assets and infrastructure that make up the Cloud service is not within the enterprise. They are owned by the Cloud providers, which will most likely have a focus on maximizing their revenue, not necessarily optimizing the performance and availability of the enterprise’s services. Establishing sound monitoring practices for the cloud services from the outset will bring significant benefits in the long term. Outsourcing delivery of service does not necessarily imply that we can outsource the monitoring of that service. Besides, today very few cloud providers are offering any form of service level monitoring to their customers. Quite often, they are providing the Cloud service but not proving that they are providing that service.

· The resource usage and consumption must be monitored and managed in order to support strategic decision making

· Whenever possible, the Cloud providers should furnish the relevant tools for management and reporting and take away the onerous tasks of patch management, version upgrades, high availability, disaster recovery and the like. This obviously will impact IT Service Continuity for the enterprise.

· Service Measurement, Service Reporting and Service Improvement processes must be considered.

Consumption and costs

· Service usage (when and how) to determine the intrinsic value that the service is providing to the Business, and IT can also use this information to compute the Return On Investment for their Cloud computing initiatives and related services. This would be related to the process IT Financial Management.

image

Risk Management

The TOGAF 9 risk management method should be considered to address the various risks associated such as:

· Ownership, Cost, Scope, Provider relationship, Complexity, Contractual, Client acceptance, etc

· Other risks should also be considered such as : Usability, Security (obviously…) and Interoperability

Asset Management and License Management

When various cloud approaches are considered (services on-premise via the Cloud), hardware and software license management to be defined to ensure companies can meet their governance and contractual requirements

Transactions

Ensuring the safety of confidential data is a mission critical aspect of the business. Cloud computing gives them concerns over the lack of control that they will have over company data, and does not enable them to monitor the processes used to organize the information.

Being able to manage the transactions in the Cloud is vital and Business transaction safety should be considered (recording, tracking, alerts, electronic signatures, etc…).

There may be other aspects which should be integrated in this Strategy document that may vary according to the level of maturity of the enterprise or existing best practices in use.

When considering Cloud computing, the Preliminary phase will include in the definition of the Architecture Governance Framework most of the touch points with other processes as described above. At completion, touch-points and impacts should be clearly understood and agreed by all relevant stakeholders.

Observations on Capability Driven Management

I’m finalizing my presentation for Business Ecology Initiative’s Optimization for Innovation conference slated for March 22nd in Washington DC.  Initially, I was approaching it as a humorous rejoinder on how to cope with taking the reigns of an or…

Stories That Move Mountains

In mid-2010 I held a series of training courses to cover many of the key techniques I’ve previously discussed on this blog. One attendee, Nick Malik, was in for his second time, the first being three years earlier. Another, Mark West, had been working with me as a contractor on a project. After the sessions Nick and I talked for a while and he suggested that I should write a book about the way I put the techniques together.

I’ve known various people over the years that have written books and it seemed like a lot of hard work, which with a day job I was not sure I wanted to take on. Move forward a month, Nick and Mark are now co-authors and we sat down to a few weekends of planning.

By October we had a plan, a chapter structure, even a name. By February we are well behind in the writing. Don’t let anyone tell you that writing a book is easy.

We have moved a long way though and I can certainly see we will be able to pull it all together. To help with the final miles of this marathon we have developed a web site where we can make a lot of the content available and also get feedback.

http://storiesthatmovemountains.com

All of the relevant blog posts from this site have been moved over and a lot more will now start to appear. This blog will now just focus on Enterprise Architect and IT topics.

Enterprise Architecture’s Obsession with Efficiency

Jeff Scott recently wrote a great blog "Is the current EA paradigm right for business architecture?"

http://blogs.forrester.com/jeff_scott/11-01-25-is_the_current_ea_paradigm_right_for_business_architecture

The comments section was full of erudite responses from several of the leading thinkers in EA. I’d like to pick up on two of the comments:

Tom Graves

"Most people seem to be obsessed by

Enterprise Architecture is Misplaced and Other News from MIT Research

Several interesting points that deserve their own blog posts, so this is just a conversation starter:- EA should not be inside of IT, and it’s usual placement hampers both IT and its effectiveness. – EA maturity is directly related to organizational pe…

Business Capability Naming and Content

Bruce Silver, BPMN luminary, has recently posted a piece on BPMN and Business Architecture where, he says, “In the past year the ‘architects’ seem to have discovered BPMN.”  WIth his usual meticulous style he dissects the difference between a process and other notions such as capabilities and functions, terms that architects like to throw around in their paperwork.

He clearly distinguishes process as the “how,” which is what we, at SenseAgility, have been saying as well. Process diagrams, and BPMN diagrams in particular, are the proof behind a particular type of capability, namely the Business Capability. In our work we’ve found that there are specific types of acceptable proofs behind different types of capabilities.

Here’s a statement Bruce makes about typing or perhaps it is even about granularity by implication, “If you’re sorting things into boxes, it doesn’t matter so much if some boxes hold square pegs and others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.” To us this principle is exactly the same one we employ when naming capabilities. As mentioned above, capabilities are different types. You can tell they are different types by looking at the proof behind the capability. That is, what makes the capability a capability in the first place? Business Capabilities have processes behind them, maybe more than one, but at least one.

So what I’m saying here is that if you want to give a name to a capability you need to have something in mind besides appropriate wording. Just getting people to agree on words doesn’t cut it. Why? Because ultimately you need to be talking about something of value. If capabilities can’t be linked to something of value then you might be imagining capabilities in a vacuum.

Anyway, subscribe to Bruce’s excellent blog when you get a chance.

Sample Set: Enterprise Architect Interview Questions

I’m interviewing an enterprise architecture candidate today. His CV suggests that he is an enterprise IT solution architect so I am going to probe a bit and see if he understands architecture of the enterprise. Here’s some questions I have jotted down as a framework for my own thinking. I’m sharing it in case it is useful to anyone else out the in the #entarch community.

What does "enterprise

Operational Capability Risk: Executive Rotation

As announced last year, I will  be presenting at the OMG Business Ecology Initiative’s inaugural “Optimization for Innovation” Conference on 3/22/11 on how an executive can quickly and efficiently analyze operations of a business unit. &nbsp…