So, What is Digital Enterprise Architecture?

Some time ago, I wrote an article about what is Digital Architecture. As a continuation of that article, also as apparently I am not very creative in finding new topics, I would like to focus on Digital Enterprise Architecture this time.

A Digital Enterprise Architecture is crucial, especially for large-size enterprises to stay nimble amid increasing competition. It is no secret that Amazon, or some other digital organisation, but most likely Amazon, is sooner or later will attempt taking over your industry.

The previous article stated that Digital Architecture is an architecture discipline applied to Solution Architecture. As would be expected, the same logic applies to Digital EA. Digital EA is essentially a modern approach to Enterprise Architecture which appreciates the impacts of digital transformation and thrives to keep the organisation stay ahead of the digital curve.

With that said, here are a few ideas for establishing a Digital Enterprise Architecture.

Disrupt Enterprise Architecture Principles

OK, disrupting might sound a bit ambitious. However, at a minimum, EA should revise architecture principles, policies and standards to enable the adoption of digital best practices and, more critically, emphasise customer centricity. Principles should not just focus on operational excellence as they would in a traditional enterprise architecture. They should instead cherish returning, happy customers. In the digital age, businesses can only survive if they pay the same or more attention to servicing their existing customers as they do to acquiring new customers.

In a Digital Enterprise Architecture, principles should be simple, practical and concise with a sound understanding of the digital landscape. Principles should emphasise customer and experience focus and inspire re-thinking. As a good example, Digital Principles provides a simple set of principles with digital themes such as Designing with the User and Being Data Driven.

Also In a Digital Enterprise Architecture, policies and standards appreciate the changes in the architecture patterns. For instance, if there is a policy against data replication, it may conflict in cases where persistent caching on the edge layers is required, or a fully-autonomous microservice is to be created. Keep in mind, even well-regarded museums are updating their principles to adapt to digital behaviours of today’s consumers.

Experience as Enterprise Architecture Asset

Key to digital is designing the right and optimum experiences for customers. In order to model such experiences, organisations today use tools like Customer Personas, Customer Lifecycle and Journey Maps. In a Digital EA, creation and re-use of these experience artifacts should be considered a norm. In fact, EA should provide an enterprise portfolio of experience assets where projects and solution can utilise to assure all segments of customers and lifecycle stages are considered.

These enterprise level catalogue of customer personas, lifecycle stages and high-level customer journey maps should then be used to derive other enterprise models where possible. As an example, a business capabilities maps should display critical capabilities that are necessary to implement these journeys and capabilities impacted by different customer personas and their lifecycle stages. This would allow help organisations create capabilities that connect with the customers throughout their lifecycle. Where experience artifacts cannot be directly used to derive other EA models, they should at least be associated. For example, an application catalogue linked to customer journeys would reveal critical applications for customer satisfaction.

Experimenting with Lightweight Governance

Experimentation is an essential capability, especially for large-size enterprises where innovation is not that great. Being able to test ideas before investing massively in them is the only way to keep up with smaller size startups or with large-scale organisations who have the resources and better at innovation. As Jeff Bezos correctly points out, ideas should only become expensive when they work.

Traditionally, Enterprise Architecture has the gatekeeping role in form of policies and standards to maintain a sustainable technology ecosystem. While governance is indispensable to eliminate unnecessary business and security risks, strict policies may stonewall experimentation or let ideas become just too expensive to try. Instead, a Digital Enterprise Architecture should promote experimentation through flexible governance models. Such models should allow business to test their ideas without having to invest in a fully-ratified solution until the idea proves itself to be profitable.

Thoughtful experimentation and investing in ideas is an essential capability, especially for large organisations, to avoid falling behind the competition. Although first-time-right might sound like a noble Enterprise Architecture outcome, you can’t pick the winners without investing in losers.

Cultivate a Design-Driven Architecture

Embracing a design-driven, innovation culture is crucial for today’s organisations. Focusing on operational excellence no longer cuts it. Although it is not easy to quantify the value of design, the Design Management Institute’s Design Value Index is a strong indicator to quantify the difference it makes. According to 2015’s Design Value Index, design-centric companies outperformed S&P 500 by 211% on returns over the 10 years between 2005 and 2015.

A design-driven architecture (I know, it sounds like “wood-driven carpentry”) would be the key enabler of a design-centric company. In an article from 2017, Gartner says 40% of enterprise architects will focus on the design-driven architecture where organisations understand the ecosystem and its actors, gaining insight into them and their behaviour and developing and evolving the services they need. In fact, Enterprise Architects, an Australian architecture consultancy re-branded itself as a Business Design firm 15 years after its foundation.

In these circumstances, Enterprise Architecture should promote design thinking within the organisation and in the architecture processes. It should also encourage, if not instruct, solution architects to spend time with the actual customers and participate in customer/user tests.

Here’s a bonus, inspirational interview conducted by the London Business School with Molly Dobson from Amazon on the culture of innovation.

Be Digital

Well, thank you Captain Obvious. But, seriously, you simply cannot have a Digital Enterprise Architecture if your EA practice, or any of your architecture practices for that matter, is not behaving digital.

EA teams should re-think and re-design their services with the focus on their customers. Are the organisation users getting the answers or guidance they require easily and timely? Is your Enterprise Architecture relevant, down-to-earth or disconnected? Are your artefacts easy to consume, or does it require architecture knowledge or special tooling? Do people have to chase EAs for critical decisions or are you proactive? Does your EA only speak about a far away future state which is not helping solve today’s problems? Or is it only an outdated documentation of the current state? Most critically, are you a gatekeeper or an enabler?

EA should also explore the opportunities to utilise technology to deliver better experiences. An example would be an AI engine running on the architecture repositories allowing users to intuitively query the architecture. Another example would be using big data and machine learning to maintain a current picture of the enterprise systems and the interactions between them.

Acting faster, bolder and smarter at the same time is an imperative for today’s businesses and it is exponentially harder for traditional organisations. Enterprise Architecture can have a role in achieving one or all of these goals. A Digital EA does not only focus on being smart and be the brakes when necessary; it is also the engine driving the change and helping the organisation take bolder steps.

Digital Thinking

design_thinking_base

Digital is big. It is not only big in the size of the hype it created but also big in its breadth and impact. It has become the codename for anything mixing the latest in technology with dazzling customer experience. Wikipedia’s definition of digital transformation refers to it as the next chapter in technology literacy where technology amalgamates with creativity and innovation.
Continue reading Digital Thinking

Surviving Bimodal IT

Hong Kong October 2013

Bimodal IT has lately become one of the hottest topics in the IT. In fact, if this is the first time you are hearing about Bimodal IT, you are more than a year late to the discussion.

There are lots of good resources describing what Bimodal IT is (E.g. this one, or this one) and likewise a plethora of flaming discussions why it is a good idea especially for digital or a bad one if not the worst.

I, on the other hand, see myself at the same distance to both parties. I believe, Bimodal IT is not a state you would be targeting nor a one you should avoid at all costs. Bimodal IT can be used as an interim model on the way to reaching IT nirvana.

IT organisations are large organisations consisting of numerous subunits which are constantly forced to change in all directions under the crossfire of new business requirements, changing market demands, emerging technologies, governance, risk and compliance concerns et al. It is therefore understandable, in fact inevitable, that each subunit of the organisation follows a different path, works with a different timetable and targets a different ideal state. In fact, I also find the similarity of the term Bimodal to Bipolar interesting, where Bipolar is used to describe a mental condition which is somewhat pertinent to what Bimodal states.

Bipolar Disorder is a form of major affective disorder, or mood disorder, defined by manic or hypomanic episodes (changes from one’s normal mood accompanied by high energy states). 

Continue reading Surviving Bimodal IT

The Return of the Digital

1a22408

As the world history repeats itself, we also see the technology repeating itself in various ways. I remember presenting an über cool, AJAX-based application development solution to customers back in 2006. I was telling how it was different to traditional web applications that it was just updating the fragments on the UI not reloading the whole page. One day in a customer demo, a veteran developer said “We had this in 80s in mainframe terminal screens and it wasn’t a big deal!” Well, it wouldn’t be a big deal for the web era as well, if HTTP was initially designed for running applications not just for document exchange but that’s another story (seriously, isn’t it surprising that young developers don’t question why there is such thing as JavaScript but start learning AngularJS straight away?).

Continue reading The Return of the Digital