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.

Read More

The Superpowers of a Technology Architect

Every profession requires special skills which make an individual best or mediocre in that field. If you are a superhero, flying without engines, seeing behind the walls or firing laser beams off your eyes would certainly make you a favourite amongst the others.

Having spent close to two decades in technology architecture, I tried imagining the superpowers of a super architect. I focused on the character skills instead of domain, technology, or methodology knowledge and experience. I believe an architect who has these skills would pull off any complex design problems even they are new in the field or don’t have a shiny architecture badge.

None of these would be considered a superpower unless it comes with a flashy name. The outcome is not as striking as Negasonic Teenage Warhead, but I tried my best.

Neutral Perception

I’m not even sure if I have picked the right words to describe this superpower, but it surely points to a fundamental skill of a good architect. Getting rid of preconceptions and listening to comprehend but not to respond is an art of mind and harder than it sounds. This article explains the science of listening, and how our brains process what we hear. We tend to handpick bits and pieces from the entire conversation which correlate to our past learnings and experiences and what we already know. Once we think we got the gist of the talk, we quickly land on a judgment and rest of the communication seems unworthy of attention. We instantly shift our focus more on building up a response than listening what the other party has to say. Although this is a common human behaviour, it is unacceptable for a super architect.

A super architect is all ears and encourages the other party to elaborate further with questions. She is keen to learn and experience other perspectives and skilled in using empathy to precisely understand different viewpoints. Stephen Covey also draws attention to the importance of empathic listening in his book The 7 Habits of Highly Effective People. If you are lazy like me to read the whole book, check out this article. It does not only point out to Covey’s empathic listening but also lists other critical communication skills.

In the end, for a conversation to become meaningful someone has to do the listening.

Random Contextual Jump

It is a great luxury for any architect to deal with only one aspect of a single solution at any given time. Usually, architects are inundated with various queries and unknowns from multiple solutions concurrently. More often than not, architects find themselves under abrupt spotlights where they are expected to explain intricate solution dependencies, comment on a compliance risk, improvise a detailed technical decision, provide a finger-in-the-air budget estimate, answer to security design questions and so on… Dealing with such sporadic variety of enquiries requires an exceptional comfort with ever-changing contexts as well as some level of Hyperthymesia.

A super architect maintains an ever-growing, multi-dimensional, non-volatile mind map of events and data in her surprisingly human-sized head. This mind map links every bit of information element to time, people, and locations where the super architect effortlessly hops between the nodes at any time of the day and under every condition. A super architect never stutters, never gives a half-baked answer, never forgets the rationale behind design decisions and never lets herself get into an “I should have said that” situation – even when she is being interrogated by a tableful of infuriating architects, aka Architecture Review Board.

Unfortunately, in reality, continuous context switching is a hideous form of multitasking. As this article elegantly points out it is also “the mother of all time sucks”. It doesn’t only kill your productivity but also lowers your IQ in some cases.

There are methods to deal with the challenges of continuous context switching such as Memory Palace or Mind Palace. If you are like me and find those methods complicated, and if you are not Sherlock Holmes, you can simply start by not trusting your memory and take notes in meetings, timely record rationale and decisions in your design documents.

Ethical Mindtrick

Powerful communication is key to designing an optimal solution architecture. With that said, an architect must also sharpen her communication skills with persuasiveness. Solution design process often involves convincing stakeholders why a particular design option is the best fit amongst others. Likewise, there are also times when an architect has to reason with stakeholders on why a seemingly lower cost, shorter time-to-market solution idea is not exactly the best option. A typical example of this is where business sees an opportunity in leveraging an existing design which is not aligned with the target architecture state of the organisation. Such quick-win, tactical solutions may result in long-term performance issues or technical debts which may not be immediately visible to business stakeholders. In a case like this, a super architect would simply wave her finger in the air while saying the following words with a soothing voice: “This is not the solution you’re looking for“.

Unfortunately as mind trick only exists in a galaxy far, far away, architects may choose to look into some down-to-earth techniques to make their communication clearer, logical and unquestionably convincing. Although these techniques are different in implementation, and a few like these may run your blood cold, in essence, they all require the architect to be the observer as well as the governor of the communication apart from being a participant of it. Architects can also shoot a glance at sales techniques as a super architect is also a master salesman of reasoning. Exploring techniques such as SPIN Selling can help architects to build up that observer perspective and have a greater command of their communications with other parties.

Hyper Cerebrum (or Extreme Learning)

One common statement used while describing the work of an architect is to suggest that she is the bridge between business, user experience, technology, operations and other stakeholders. A better way of looking at this is to consider the architect, not as the bridging role in between but as the intersection of all of these roles. That essentially means a super architect would design the best customer experience while creating the most profitable solution. Likewise, she would understand the business and even figure out how to fence off the competition. She would also appreciate the risk, compliance and legal impacts. At the same time, she would be the master of all the relevant technologies no matter how contemporary or antiquated they are. She would also know the ins and outs of DevOps, release and test management. She would even know Kung-Fu if necessary.

Vitruvius, the author of the first book on architecture theory takes the definition of the ideal architect (i.e. super architect) a step further in his book:

The ideal architect should be a man of letters, a skilful draftsman, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations.

Sadly, humans have limits and no one is born with innate knowledge of everything. However, a good architect should be passionate about learning new things whether technical or business related. Just like an accomplished detective, she should develop her methods for getting to accurate information. She should enjoy chatting with people from all parts of the organisation and encourage them to talk about the issues they have and the details of their work. Also, she shouldn’t mind digging shared portals, wikis, document repositories to access to bits of information and connecting the dots. Additionally, she should follow industry news to keep up-to-date with the outside world.

Along with learning new things, she should also work on enhancing her learning skills. This article slightly touches on the science behind learning and provides some tips on learning faster. As the article points out, practice makes perfect and learning new skills helps the brain pick up further new skills more comfortably.

Crystal Articulation

We all heard of philosophical conundrums probing the relationship between perception and existence of things. There are a number of these but I believe the most commonly known is this one: “If a tree falls in a forest and no one is around to hear it, does it make a sound?“. Here’s a collection of answers to this question for the interested.

Here, I want to pose my own philosophical conundrum:

If there is a great architectural design and yet it is articulated very badly, is it a great design?

Powerful articulation is an essential skill of an architect. It goes beyond accurately expressing the facts visually or verbally. It is about using correct articulation techniques to ensure the message is delivered to the right direction with the right context. Here’s a great story about Harry Beck and his map of London Tube. Beck created his map back in 1933 and it became the standard for all metro maps. Beck’s map was not interested in depicting railways, stations and landscape accurately but to convey information to its consumers in a manner that is useful to them.

Just like Beck, a super architect creates the optimum design artefacts and chooses the optimum words, creates architectural seer stones, and delivers the rationale and impact of her designs exactly from the audiences’ viewpoints. Anyone interacting with the super architect – or with the artefacts she has created – would leave with zero questions lingering in their minds.

When it comes to creating diagrams, there are lots of best practices out in the wild such as Geert Bellekens’ 5 rules for better diagrams. However, I believe the magical ingredient is empathy and focus on how the information can be best conveyed to its consumer. For instance, in some cases, it may be better re-drawing a diagram on a whiteboard while telling the story of the solution, instead of simply presenting an existing diagram.

Atlassian Endurance

Endurance doesn’t sound like a flashy superpower but it is a complementary factor of a superhero character – in some cases making the mere immortals get closer to superheroes.

Architects fed on uncertainty and their job essentially is to facilitate change in a good direction. Change is not always easy and as Dan Heath, co-author of a couple of books on change, points out in this short video, it may even get you exhausted to a point you don’t really care anymore. Architects tell people that things are going to change, and they may even have to step into new, unknown territories. In many cases, people will be reluctant to change or won’t fully agree with the direction architect is pointing at. Even architect herself might have inner debates on how to get there. She would question whether she should compromise on the architectural principles to deliver the business value earlier, or whether she should say no to the business sponsors to avoid technical debts. Either way getting from an idea to a delivery-ready design is a pretty exhausting task and architects should find ways to keep up their willpower.

One easy method is simply to accept the fact that non-architectural tasks of chasing and convincing people, having endless discussions and developing business cases are also part of an architect’s job. If it helps, architects can imagine themselves as management consultants sent to a client to develop business. As a dexterous consultant wouldn’t leave the client without a meaningful outcome both for the client and herself, an architect should also display the same endurance in order to get to the best solution for the organisation.

This wraps up my list of superpowers a super architect must have. Anything missing or doesn’t make sense? Let me know in the comments.

Read More

What is Digital Architecture anyway?

Best way to secure funding for your project is to put the word Digital somewhere into the name of it.

Those were the words I heard from a IT executive pretty much summarising the way IT industry reacts to Digital today. We work in digital transformation projects which would be just called transformation projects a few years ago.

Unsurprisingly companies are seeking for Digital Architects to support these projects, whereas they would be just looking for Technology Architects before digital became the fund-securing-word. Funnily enough, if you look at to required job skills, you can hardly spot any significant difference apart from some key words.  So what makes an architect a Digital Architect and in fact, is there such thing as Digital Architecture?

Short -and vague- answer is, “no… but sort of there is…”

There are a number of known architectures which deal architecture in different layers. Enterprise Architecture deals with architecture from a strategic, big-picture standpoint whereas Information Architecture works specifically in the data domain. Not to mention the architectural styles which keep the IT industry going as the newest is always better than the preceding (E.g. service oriented architecture vs micro-services architecture).  Obviously then there is solution architecture which glues all these together around a particular solution.

Digital architecture, is not really a new type of architecture nor an architectural style – hence the vague short answer. It is more of an architectural discipline applied to solution architecture. Although we tend to see digital somewhat analogous to application of technologies like APIs, big data analytics and such the real essence of digital architecture lies in the way it approaches to problems. Technology definitely being its favourite tool, digital architecture redefines the solution design process and shifts the focus from the problem to experience. Thus, the architect who rolled her sleeves to become a Digital Architect must appreciate this shift and be keen to refresh her thinking about the design methodology.

Digital Architecture redefines the solution design process and shifts the focus from the problem to experience.

Here I would like share what I believe are the key traits of digital architecture design process. You will see that some of these could be considered as common architectural qualities and some might be read as how architecture should be done in digitised organisations.

Collaborative Design

Traditionally solution design awaits delivery of requirements and architects define the solution outlined by the given requirements. This would create an isolated design space where architects can deliver their blueprints relatively in comfort. However it may also disconnect them from the actual landscape. Architects might miss what actually matters for customers (or users) and most importantly what the real opportunity is. It is essential to note that digital deals with the overall experience not just the delivery of a product or a service. Architects may deliver a far better solution by liaising with the people from the field and listening to actual users about their experience. They can drive the solution by facilitating design workshops and using techniques like Design Thinking.

Speed Governance

Digital loves speed. Real digital organisations thrive to create customer delight in the speed of idea. Good organisations achieve high velocity by properly adopting agile principles and devops practices. There are also new operation models such as two-speed IT which aims to attain speed by freeing the digital half of the organisation from the heavy controls and processes. This may seem like a noble cause at first as organisations usually develop such controls and processes organically which then often replace the actual purpose. However it is also known that deregulation tend to create its outlaws. Digital Architects may find themselves surrounded by digital cowboys, both from the business and technology side, who hold the very next release higher than the overall goals and the target state of the organisation.

Governance is even more critical for digital as things can get out of hand easily in the fast pace of delivery.  However traditional governance won’t cut it for digital hence Speed Governance is needed; which is a subject for another blog post.

Continuous Experience

Experience is the keyword for everything digital. Another keyword is omni-channel which emphasises the continuity of the experience across all customer touch points. In fact continuity should occur in various dimensions for lasting good customer experience. Architects should consider the whole customer & service life-cycle and their interactions with the organisation while designing solutions. Will the customers get the same omni-channel experience after purchasing the product or service if something goes wrong? Are there sufficient operational controls to provide a seamless, problem-free experience? Can the solution self heal? Is there intelligence built into the solution to personalise the service? Put in other words, architects should be concerned more about the good customer experience than fulfilling requirements.

Sincere Design

Associated with customer experience, this is perhaps the most critical, distinguishing feature of digital solutions. Digital savvy customers will know what to expect from your services and with more digital competitors about leaving your services for a new provider will be as easy as installing a new mobile app. In a digital market, acquiring and retaining customers is even more challenging and the best way to accomplish those is sincerely putting customers’ interest into the center of all activities. Architects should guide the business and technology stakeholders to deliver a solution which creates the best outcome for the customer. They should advocate customers’ interest in their solution discussions and challenge the norms when necessary.

Know Thy Technology

This may be again considered a common virtue for architects but as digital is considered closely with adoption of new technologies, being hands-on is a differentiating factor for Digital Architects. Digital Architects should be able and willing to play with the technologies they may incorporate into their solutions. Ideally, they should also participate in hackathons, lead spikes and proof of concept activities and implement frameworks. This way they can develop a solid command on the technologies and assess their strengths and weaknesses consciously. They can also better understand the dependencies and what would be required to employ the technology at the enterprise scale.

Needless to say, there are more than these characteristics to digital architecture. I highlighted the ones which I feel essential for delivering digital solutions. Going back to my initial question, do you think there is such thing as Digital Architecture? of What is Digital Architecture for you?


Read More

Digital Thinking


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.

It is obvious that technology is a significant component to digital transformation but one should not make the mistake of deeming it as the most essential ingredient. In fact, in some business domains a successful digital transformation could be achieved through existing, legacy technologies by just re-thinking, re-focusing and re-visiting the customer experience. That points us to the must have ingredient of digital transformation: an obsession for providing the best customer experience. Surely, customer experience has a number of aspects. It is not just about creating beautiful mobile apps. In fact, a good customer experience should exist without any technology around. It must be ubiquitous, consistent and continuous.

Digital presents an opportunity to organisations to re-visit and digitise their businesses in the light of new trends and technologies. It is up to organisations to take this opportunity as a chance to create something better or something awesome. Are you just trying to automate your existing processes? Or just re-creating the same experience on different screens?

If you are truly set out for creating the awesome, the basic and lasting question for you to answer is: “what is the awesome experience?â€� How can you create the differentiating experience hitting the bullseye – not what you preconceived as the best – for your customers?

Here Design Thinking can provide you proven methods for tackling complex unknowns and finding appealing – and sometimes unexpected – new solutions.

Design Thinking has a number of definitions, here is the one from Tim Brown, whose name became synonymous with the concept:

Design thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.

As Tim’s definition points out, design thinking is a reliable approach to innovation. Having its history going back to early 1990s and involving people like Hasso Platner, design thinking is not a prescriptive methodology. There are various design thinking implementation methods with similar process steps but with some nuances. Here is a great article describing these methods, similarities and differences.

I will take the approach defined by Stanford University’s Institute of Design (a.k.a. and try to explain how design thinking and digital transformation can go hand in hand to form Digital Thinking on the path for creating the awesome.



Putting customer into the centre of innovation is the primary principle of a digital organisation. This step in the design thinking process also emphasises the necessity of listening to end consumers and collecting enough data to be able to see things from their viewpoints, understand the real pain points and create the best-suited solutions. Digital teams can utilise the tools defined in the Empathize step to better understand their customers and design experiences from their perspectives.

They can even use technologies as real-time data analytics and event processing to embed empathy into their solutions (although that is not exactly the kind of empathy Empathize step is about).


This step in the design thinking process is about framing the right problem in order to create the right solution. In this step, teams use the data they have collected in the previous step and outline the actual problem that is bothering the customers, or the solution which would delight them most. Defining the problem or the solution space correctly is also a key step in a digital transformation. As the objective is to put the customer into the centre of innovation, digital teams (or task forces, or squads) then can be built around these defined areas to create the experiences closer to customers’ hearts.

In fact, this step should be the genuine driver to agile architecture and design works instead of a huge pile of business requirements documents.


Digital organisations must thrive to explore unprecedented and awe-inspiring ways to engage to customers using existing or new channels. This step in design thinking process allows teams to come up with the broadest ranges of ideas to solve the problem identified in the Define step. Digital can even further heat up the ideation process by its openness to try new technologies. Teams can build ideas around wearables, IoT, virtual reality, 3D printing, telematics, bots and many other modern technologies to enrich the channels of engagement and the experiences.


Quickly prototyping the idea will allow you to test your solution early in the process. In this way, you will be able collect rapid feedback from the field and re-visit your solution as necessary for the next iteration. Design thinking suggests creating quick and cheap prototypes for the initial iterations and refine it further along the process. In a digital transformation case, the initial prototype can be a simple drawing of screens, an enactment of an experience using pseudo gadgets and systems. E.g. A wearable made of cardboard sending data to an imaginary system displaying reports on a screen drawn on paper. As the prototype gets closer to reality, digital teams can use cloud, open source technologies, public and commercial APIs, and the humongous range of Software as a Service offerings to create more interactive, cheap, disposable and easy-to-build versions of the prototypes.


Testing your idea – using the prototypes you have created – is obviously a great way to test your solution. Is your solution intuitive, has your test group got excited with the experience? For a digital solution, in the infant stages of the prototype it might be easier to test and collect the feedback. As the prototype gets sophisticated, digital teams should also find the ways to embed

There are a good number of articles and stories out on the internet regarding design thinking. If you are also interested in applying design thinking into your digital transformation, a fun way to start is could be just watching this movie.

Read More

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). 

Bimodal IT, in a nutshell, describes an IT organisation which organises itself under two modes. Mode 1 is the traditional IT organisation, where security, governance, compliance, and stability is the king and Mode 2 is the startup-like IT where innovation, experimentation, speed and agility is A1. Or, in a more informal way, Mode 1 is the guy who wears shirts and trousers to the office and works hard to send those financial figures to partners accurately and securely, whereas Mode 2 is the guy wearing t-shirts and jeans and works on a wearable tech for paying the beer with a brofist.

From the business perspective, Mode 1 is better suited for management of the organisation’s money whereas Mode 2 focuses on making even more money.

Surely Bimodal IT presents a formula to CIOs who are looking for ways to to enable agility and innovation while making sure business goes as usual, data is stored and shared securely, risks are handled properly, compliance is managed meticulously and so on. Bimodal IT tells CIOs to split IT into two sub-organisations and treat them differently. Basically, let Mode 2 be more free of the processes and methods Mode 1 has to follow and let Mode 1 be whatever it used to be.

At the outset, Bimodal IT looks like a way out for the CIOs, in reality it does not represent a stable IT organisation for multiple reasons:

  • Subtext: It is ineluctable that the subtext of Bimodal IT will read:  “Mode 2, you are the cool kid and forefront of innovation, and Mode 1, you are now officially old school.” That is clearly an open call for tension between organisation units if not managed properly.
  • Mode 1, Mode 2,..Mode n: Most IT units are likely to be a mixture of modes and none of them would like to be tagged as not-that-agile or not-that-stable. There will always be in-between modes.
  • IT Bipolar Disorder: As one person cannot leave a healthy life with mood disorder, an IT organisation cannot survive with two modes, especially when there are strained relationships between the modes. It needs of all its subunits to work together towards the common goals.

After all, even if IT manages to work in two speeds, actual business cannot be delivered under distinct modes. For instance, a company cannot have a Mode 1 and Mode 2 type of sales processes. Customer experience must be consistent across all the channels and throughout the lifecycle of the relationship. A business needs all of its units to work in harmony and be agile and stable as necessary to enable innovation while increasing profits and maintaining its reputation in the market.


In short, Bimodal IT is not a cure for an agile IT, but it is the diagnosis of the fact that some parts of your IT organisation are not agile enough, and when they are, they sacrifice on safety and accuracy.

Going back to what I said earlier, Bimodal IT is not an end state but an interim state on the way to Nirvana IT. It can help you identify which IT subunits need to change in what ways to become an agile yet stable IT unit. It can also serve as a map to flesh out agility and stability levels of IT subunits so you can investigate the options on how nonlinear, exploratory units can work with more traditional, linear ones.

It must also be noted that it is not always straightforward to avoid linearity and waterfall processes in some situations:

  • Bureaucratic Service Providers: Almost every IT organisation work with external service providers. Some service providers are sensitive on risk and might like to handle every simple request as a new project with statement of works and approvals etc, eventually causing large linear steps in project lifecycle.
  • Old School Technologies and Vendors: In some cases, legacy, non-agile-friendly technologies or traditional vendors can hold the teams back from being more responsive to changes with their lethargic product development cycles, sluggish support and perplexing licensing models.
  • Overutilised Shared Services: Shared services might be lacking the human power to meet desultory requirements coming from all directions and might prefer a waterfall approach in their response to sustain their resources.

However, in the grand scheme of things, the fundamental barrier to achieving IT agility is the IT organisation itself. It is

  • The culture it has cultivated over the years
  • The way it has structured its organisation hierarchy
  • The way of working organically developed throughout its lifecycle
  • The nature of relationships with business and other stakeholders (open vs defensive)

All these reveal the true medicine to achieving a stable and agile IT is a sincere, well-informed and determined change.

IT leaders must lead the organisation to change in an agile manner. Set long term target and transitional states and make the change a substantial theme to the everyday work.  They also have to maintain their tough-minded optimism as organisational change is certainly not a walk in the park.

The next vital step after acknowledging the existence of two or mode modes is to get these to work together efficiently and release the tension between the modes.

There are two prominent models in the industry:


Squadification is a model developed at Spotify to enable agility while scaling up the organisation. It is based on the idea of self organising teams. Squadification introduces team structures such as squads, teams and chapters. Squads represent the smallest, autonomous team structure which is build around a common mission – as opposed to traditional team structures built around systems, business domains or common functions. Squads are a great opportunity for creating alliance between the modes around common ideas and goals (e.g. “let’s create the fastest, low-risk loan on-boarding process”.). Squads also provide an amicable atmosphere for people from different modes to appreciate their differences and the challenges they face. Most importantly, Squads allow the modes to innovate and get things done rapidly without the boundaries and restrictions put by the organisation culture and hierarchies.

Squadification also defines methods and structures for inter-dependency management and alignment to company’s higher strategic goals while empowering people to choose the methods and land on decisions easily.


Check out these links if you want to learn more about Squadification:

Scaled Agile

IT leaders who would like to try a bit more closer-to-traditional-corporate, less-experimental models can also look into scaled agile methodologies. Bimodal IT points out the duration of change cycles as another difference between modes. In a mode 1 organisation cycle times are long where in mode 2 changes delivered in days or weeks. Scaled agile methodologies appreciate these differences and offer agile frameworks for aligning the change cycles in different layers.

Being the most known scaled agile methodology, SAFe® (Scaled Agile Framework) defines four different levels to deliver change along with the coordination processes between the levels. These four levels are Portfolio, Value Stream, Program, and Team. These levels and the coordination processes allows corporates to align  bigger transformation programs with strategy, budget and strategic architecture (Portfolio-level) and bigger transformations (Program-level) with smaller sprints (Team-level).  SAFe® also defines inter-level processes such as the architectural runway which helps identifying and managing the  dependencies between the modes incrementally.


Check out these links to find out more about scaled agile:

Read More

Implementing Disruptive Technologies: 8 Lessons Learned from SOA

It is true that SOA has lost a lot of its steam now and the craze of SOA has been overtaken by the charms of new disruptive digital forces namely cloud, big data, social business and mobility. As with every emerging technology climbing up to the peak of the hype cycle, those digital forces are fully loaded with promises and expectations but it is only a matter of time that they will crash into the harsh wall of reality. This story is not new, and has also shown itself in the “SOA is the savior” era. The goal of this blog is to remember that story once again and come up with a list of lessons learned, which might hopefully guide architects and implementers of the new digital forces.

Read More

Monitoring SOA Critical Success Factors

Screen Shot 2013-10-06 at 7.58.45 PM

Apart from tracking dependencies between SOA elements and managing the service life cycle, one of the indispensable tasks of SOA Governance is to control and manage SOA success. Successful implementation of a service architecture can be measured via certain indicators, also known as the Critical Success Factors (CSF). Every SOA adoption initiative should incorporate a step, ideally right before the architecture blueprinting phase, where unique success factors regarding the adoption are defined. This step should also outline the tools and techniques to be used in monitoring the success factors and together they should form the CSF Specification. CSF Specification could also be refined and improved throughout the adoption process to conform with common Enterprise Architecture(EA) practices.

Below, you can see a list of generic SOA CSF, with hints on how they can be monitored with SOA Governance:

  • Alignment with Business
    For a SOA implementation to deliver the business benefits and expected ROI, it has to provide business services aligned with business processes. This alignment can be monitored with design-time policies and service classifications based on business process frameworks. E.g. a Telco company can use TM Forum Business Process Framework (eTOM) to classify its business services (A business service classified under the category of “eTOM > Operations > Resource Management and Operations > Resource Provisioning”).
  • Re-usability & Conformance to Architecture Blueprint
    High re-usability of services is critical in achieving SOA success. To increase re-usability of services while keeping the complexity of SOA at minimum, architecture blueprints should define service design principles, technology standards, common business and technology terminology, canonical information models, reference architecture and so on. Monitoring conformance to these architectural artefacts can be attained with the help of design-time policies along with associations of services to architectural artefacts in the SOA Governance Registry and Repository. E.g. A design-time policy where a service is reviewed and approved by an Enterprise Architect.
  • Business Agility
    Enabling business agility is one of the key success factors for SOA. Business agility can be achieved with shorter development cycles, shorter change management cycles, and lower development and integration costs and also with right service design. To monitor development cycles and costs, SOA Governance Registry and Repository can be enriched with new asset types and attributes. E.g. a Project asset with attributes, project start date, project finish date, project cost, number of re-used services, number of new services etc.
  • Sustainable Service Architecture
    SOA implementation is not a one-time project but an ongoing process constantly aiming to achieve better business agility with lower IT costs. To sustain successful service architecture, it is essential to keep an updated record of design and implementation artefacts. SOA Registry and Repository can provide a central repository for storing artefacts, and design-time policies can ensure the timeliness of the repository. E.g. a design-time policy which only allows a service to go into test if right documentation is in place and stored in the repository.
  • Readiness for Production
    Services should be ready to handle the production load. Production conditions such as average number of requests, peak usage hours, average message size, minimum response time, required availability should be specified in Service Contract artefacts and these contracts should be attached to Services. To monitor the readiness for production, a design time policy which compares service test results against the conditions in the service contract can be used. This policy can also be supported by an approval workflow.
Read More