Author: Scott Comte

What has a greater impact on Digital Transformation: Enterprise Architecture or Business Architecture?

Written by Scott Comte on February 21, 2018. Posted in Articles.

Around this time 12 months ago Gartner predicted that half of EA Business Architecture initiatives in 2018 would focus on defining and enabling Digital Platform Strategies.

While there hasn’t been follow-up research to prove whether this prediction has come true, anecdotal evidence would suggest that the real situation is pretty close.

In the research Betsy Barton, Vice President and Distinguished Analyst at Gartner stated:

“The increasing focus of EA Practitioners and CIO’s on their business ecosystems will drive organizations further toward supporting and integrating business architecture. This is to ensure that investments support a business ecosystem strategy that involves customers, partners, organizations, and technology.”

The core output of a Digital Transformation, from an IT perspective, is the development of supporting digital business platforms. However, with the growth of cloud-based services success in this transformation process is less a technology challenge and more a Business Model challenge. Digital Transformation can provide an opportunity for organizations to do business in a totally different way. But the fundamentals of business in a digital and traditional world remain the same. To run a sustainable business, you need to deliver a product/ service to customers that meet their needs in an effective and efficient manner and ensure that you continue to evolve that product/ service so that it continues to meet customer needs into the future. And you need to make a profit doing it. So you need to have a Business Model that achieves this.

Enterprise Architecture is very good at defining, and bringing a semblance of order to, the complex ecosystems that make up a business, particularly from a technology perspective. However, business architecture is what brings it alive. This is what Gartner calls this business-outcome-driven Enterprise Architecture, which emphasizes the importance of understanding the business and how it executes on its value streams.

TOGAF practitioners will proport that Business Architecture is an inherent part of the Architecture Development Method (ADM), which is true. However, I would argue that Business Architecture should be the key driver of the ADM to deliver a successful Digital Platform Strategy, rather than focus on some of the more traditional governance elements of Enterprise Architecture.

The really interesting aspect of the Gartner research is that Ms. Burton advises that one of the keys to success for the implementation of successful digital platform strategies will be the ability of organizations to integrate with other businesses digital platforms. While this will be a significant technical challenge, the key to deriving real business value will be ensuring that the platform and integrations align with the organizations strategic intent and support its value streams. In this context, Enterprise Architects will not only need to understand the business drivers and outcomes required by their business but also the needs of their partners in the digital ecosystem.

This ability to support the innovation agenda that is driving Digital Platform Strategies has also seen the rise of a new Architecture skillset, design-driven architecture. Gartner advises that “design-driven architecture will allow organizations to understand their ecosystem and its actors, gaining insight into them and their behavior which will allow organizations to develop and evolve the services that they need and consequently deliver on their business objectives.” In effect, it will allow Architects to be more customer/ human centric in their designs to better meet the increasingly complex needs of customers/ stakeholders. The key skillet that will be leveraging is Design Thinking or Human Centric Design.

With millions of dollars being pumped into Digital Platform Strategies the pressure on Architects is significant. They need to be able to manage the need to innovate organizations Business and Operating Models, often within Agile Development environments, while ensuring the interoperability of these platforms with other players in the organization’s ecosystem. In addition, they need to delight their customers/ stakeholders and in the private sector deliver a profit! With the continued development of Cloud-Based Services, the challenge of delivering these objectives by developing successful Digital Platform Strategies will be less of a technology challenge and more a business challenge.

When I initially posed the question of which discipline, Business or Enterprise Architecture, has a greater impact on Digital Transformation it wasn’t to say that both weren’t important. However, if you look at the underlying value proposition of Digital Transformation, it’s about doing business better and more efficiently by leveraging technology. To fully realize this promise the business models and value streams that deliver these outcomes need to be defined and tested based on customer/ stakeholder needs (Design Thinking) before the development of the technology platform to support them. It is, for this reason, I believe that Business Architecture will have a greater impact on Digital Transformation initiatives than Enterprise Architecture!

Does Agile need Architecture to be successful?

Written by Scott Comte on January 31, 2018. Posted in Articles. 1 Comment on Does Agile need Architecture to be successful?

On a recent Agile training course, the instructor opened the session by saying “Agile without a plan is just chaos!”

I would like to propose that Agile without effective Architecture will eventually lead to chaos, particularly if organisations try to scale their Agile practices without some form of guiding framework.

The fundamental reason for this is that we all operate within constraints, which can be financial, regulatory, technical or customer driven. While Agile practices have traditionally been confined to software development there is a significant push by organisations, particularly at the Enterprise end of the market, to use Agile practices to manage traditional business functions. This new trend is euphemistically referred to as New Ways of Working. The benefits of leveraging Agile practices are numerous, with the fundamental benefit that organisations see Agile practices as a way to deliver improved outcomes for their customers and stakeholders, more efficiently and consistently.

There are numerous case studies citing the achievement of these benefits at a project level, but very few examples (to date) of successful Agile Transformations at Enterprise Scale. Proponents of Agile practices will point to the Spotify Model as proof that Agile Practices can be used to build a $13 billion Enterprise.

Which is true, however, they didn’t do it without Architecture. They did it by leveraging Architecture and its practices as an enabler and not a governing framework. The way that Architecture worked within Spotify is quite different to how Architecture currently operates within Traditional Brick and Mortar Enterprises.

It is very hard to find a clear definition of the role of Architecture in Agile. The SAFe (Scaled Agile Framework) framework has done the most to identify the role of Architecture within an Agile environment. As with all things Agile the focus is to create consistent value and Architecture is no different. In SAFe they define two distinct elements of Architecture:

Emergent Design
Intentional Architecture

Emergent Design provides the technical basis for development and the incremental implementation of initiatives. It helps Designers and Architects to be responsive to changing customer/ stakeholder needs to ensure the initiative continually delivers value. At this level SAFe practitioner’s see Architecture as a collaborative and interactive exercise through which the design element can emerge.

Intentional Architecture is a much more structured approach and more aligned to what many would identify as being traditional Architecture, that is a set of defined and planned Architectural initiatives which will both support and enhance the performance and usability of the initiative. In effect, Intentional Architecture is a clear recognition that we all need to operate within certain constraints such as choice of technology platform, financial budget, etc. If these constraints can be identified and incorporated into the initiative then the probability of the initiative being successful and delivering value is increased.

SAFe practitioners proport that by balancing Emergent Design and Intentionality Agile practices can be scaled to deliver Enterprise level solutions. In Safe this combination is referred to the Architectural Runway which provides the technical foundation for creating business value. Which is in complete alignment with traditional views of Architecture.

The key to the success of this approach is the level of abstraction at which the balance of Emergent Design and Intentional Architecture occur. The fundamental behaviour that will determine this is collaboration. Architects need to be able to work productively with Agile Teams to provide fast and local support to manage Emergent Design while also helping Agile Teams to appreciate and navigate the constraints defined by the Intentional Architecture. One of the key attributes of Agile Practices is the fact that Agile Teams are encouraged to provide constant feedback to their stakeholders. As emergent designs develop Architects can use this information to adapt and develop the Intentional Architecture to ensure that the overall Architecture of the Enterprise is evolving with the organisation in the medium to long term.

So does “Agile need Architecture to be Successful?” I would say the better question is “What type of Architecture does Agile need to be successful?” Agile requires Architecture that supports the way the Agile Practices deliver of outcomes (value). The type of Architecture that will do this will be a combination of a nimble reactive style of Architecture supported by a more traditional structured approach to Architecture. The challenge as with many things is to get the mix right!

Business Architecture in an Agile World – the What and the How.

Written by Scott Comte on January 11, 2018. Posted in Articles. 1 Comment on Business Architecture in an Agile World – the What and the How.

My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.”

This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!

Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.

The principles of Agile are very straightforward. Agile methodologies focus on the following:

Individuals and Interactions rather than processes and tools
Working Solutions rather than comprehensive documentation and project plans
Customer collaboration rather than contract negotiation; and
Responding to change rather than following a plan.

For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.

For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.

I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.

Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.
Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.

So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.
In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.

This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.

I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.