Vincenzo Marchese

Architetural Thinking Blog

Architecture as a Business Capability (October 2012)

I think of IT Architecture Capability as the combination of people (their competencies and skills, regardless of their team names or job titles), methods, information and supporting tools that allows an organization to consistently produce IT products with a fit-for-purpose architecture, cost effectively.I believe that Architecting IT solutions that are fit for purpose is an important business capability in many enterprises. Not strategic, in most cases, but definitively important. It needs to be done well, and it needs to be done cost effectively.Being a business capability, I would argue that the architecture practice of an IT organisation should be run like a business, competing with other business capabilities (marketing, operations, sales, etc) for organisational resources to generate value that exceeds the cost of capital. As such, traditional technical competencies are necessary but insufficient to be successful. An organisation designing the best cars in the works, will fail without supporting competencies in marketing, production, performance measurement, supplier management, quality, and many other disciplines.Ultimately, to be successful, an architecture practice needs to provide to its stakeholders (within and outside IT) what they need, cost effectively. Worth repeating: to be successful, your architecture practice needs to provide to your stakeholders what they need at a reasonable cost.

Not deliverables, but architecture consumables (November 2012)

Let’s face it: IT architects produce a lot of what I would call “architectural waste”. Too often, the focus is on architecture deliverables. We deliver them, and then we start working on the next deliverable.Unfortunately, architecture deliverables that remain “unconsumed” are not generating value: yes, it’s architectural waste! Think of the IT Value chain: what we produce should be consumed by the next step in the value chain to ultimately generate value to the firm. Another useful metaphor is that of intangible assets in a balance sheet: an architectural asset is such only if has a value and can be turned into cash! If the cost of acquiring the asset is greater than the actual value, you will need to write off at some point in the future.A roadmap that remains on a powerpoint slide, a solution architecture ignored by the project delivery team, a too abstract corporate data model, an unrealistic target application architecture, a forgotten architecture vision: these are all examples of architectural waste. To avoid this, we need to make sure that they are considered as assets and therefore consumed by the next step in the value chains, and eventually become value delivered to the firm.We should stop thinking in terms of architecture deliverables, and start thinking in terms of architecture consumables. Here are a few tips on how to do that:

No more deliverables, but architecture consumables….

Architecting Capability and Architectural Significance (July 2013)

Building and maintaining a mature architecting capability is not cheap, especially in large global organisations. Typically, with a program/project portfolio in the hundreds, it is impossible to assign good architects to cover the entire portfolio.Even merely trying to achieve an effective architecture governance, well integrated with the broader IT governance processes, is in itself challenging and often impossible for a portfolio of that size!Relatively to many other IT areas, architecting is an expensive activity, and investing in it must make business sense. Just like architecting in the construction’s industry, you wouldn’t hire a top architecture firm to extend your kitchen or build a standard block of flats; not only you would struggle to hire and retain a top architect and make the most of her expertise, but also the cost of a top firm would not be justifiable for such projects.Allocating the best architects where it is most needed happens ad-hoc in small IT shops, but with portfolios in the region of several hundreds IT programs, and a typically resource-constrained architecting practice, in large organisations the work of highly skilled architects must be prioritised systematically.This can be achieved by introducing the concept of “architectural significance”, and classifying the entire portfolio accordingly. Typical values of architectural significance are High, Medium, Low and Unknown. As a rule of thumb, less than 5% of your portfolio should be of Unknown Architectural Significance (UAS) at any time, and publishing monthly metrics on the architectural significance of your portfolio is a good incentive to minimise the “unknown” and build a good understanding on the architectural relevance of the program portfolio.Once you understand where the architectural need is greatest, a more optimal resource allocation is possible. For programs of High Architectural Significance (HAS) it makes sense to assign good architects from early on to collaborate with the program on a continuous basis, often with the responsibility of leading the architecture and design work. For programs of Medium Architectural Significance (MAS), a one-off architecture review is normally sufficient, whilst no architecture engagement is typically required for programs of Low Architectural Significance (LAS).To make this work, an effective collaboration with portfolio/program/project managers is required, and these are some good practices to encourage that:

I have introduced architectural significance as a way to modulate architecture engagement twice now, and I know it works.

Minimum Enterprise Requirements (September 2014)

Believe it or not, many people in IT and business are still struggling with the concept of Enterprise Architecture, and the actual value it provides to the organisation. The theory is clear, less so how it translates into real value in practice.The need for well articulated and clear Requirements, however, is well understood. And people generally understand that designing and implementing IT Systems to satisfy requirements generates value to the firm.Rather than EA and Architecture Standards, I prefer to talk about Minimum Enterprise Requirements (MERs).Enterprise Requirements are requirements that exist beyond the boundary of a project or program. They are Minimum when satisfying them is not discretionary. Typically, requirements deriving from a security policy, regulatory demands or strict business constraints are good candidates for MERs.A MER is a requirement coupled with a clear applicability trigger criteria. This is important, because designing and implementing MERs can (and normally is) expensive. Whether a MER applies to a specific IT System needs to make business sense. Implementing Security MERs to provide a very high level of assurance, for example, makes only sense if the IT System stores/processes/displays data that is classified as strictly confidential.I often use the example of Building Regulations to explain MERs and triggers.MERBuilding regulations contain the rules for building work in new and altered buildings to make them safe and accessible and limit waste and environmental damage. People carrying out building work must usually arrange for their work to be checked by an independent third party to make sure that their work meets the required standards. In some cases the installer can certify themselves that their work complies (https://www.gov.uk/government/policies/providing-effective-building-regulations-so-that-new-and-altered-buildings-are-safe-accessible-and-efficient). In other words, if you’re building a hospital, there is a MER for disabled access. It’s applicable to all hospitals, and is not discretionary!To evaluate whether a MER is a good MER I have devised a TUSIV test. As such, MERs must be:

What is Architectural Thinking (March 2015)

Thinking becomes architectural thinking when at least two criteria are met:

• --> back to top

Architectural thinking requires navigating and making trade-offs decisions across several (3+) dimensions. For example, thinking architecturally about a new building should probably consider at a minimum the dimensions of landscape, space, time, and people. For digital enterprises, business needs, cost, resilience, security, and usability are typically important architectural dimensions.

• Home