So, What is Digital Enterprise Architecture?

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

How to successfully fail Digital Transformation

How to successfully fail digital transformation

It is nearly impossible not coming across an article or a post about digital transformation on any given day. I can at least guarantee you have seen one today.

Considering the profundity of digital, the abundance of content on digital transformation must be expected. I think all industries, governments and even the society are still in the process of comprehending what digital truly means. Everyone who has seen that mm-hmm moment would have definitely developed second thoughts about the opportunities as well as the threads that come with digital. To me, it is somewhat akin to discovering plastics; the scientific wonder of the early 1900s, now an environmental curse. It is for that reason now we are talking about everything digital; digital economy, digital culture, digital government, digital thinking and so on.

As with every new technology evolution, there is also an abundance of content on how some large organisations tried digital transformation and failed spectacularly. Some even take the bar higher by predicting that 90% of digital transformation projects will fail. McKinsey also draws the attention to digital strategies organisations have today and signals that they are likely to fail if they don’t fully understand the digital economy and its demands.

One, who reads these downhearted articles and listens to failure stories, might for a second think there is a demand for failure in digital transformation. This article is inspired by that fictitious demand, but I trust you appreciate what is the actual point here.

Without further ado, here are my tips for successfully failing digital transformation.

1. It is all about mobile apps and web pages.

Chances are your company already has web and mobile applications. You might become “digital” by refacing those apps and adding some new cool features without actually thinking about the overall customer experience. If your company has no mobile apps, you should definitely take that as a golden opportunity and create as many mobile apps as you can. There may be functional overlaps, your customers may have to install 20 different apps and end up calling the customer centre but that’s OK. Digital is speed and you certainly don’t have time to understand the digital economy and its dynamics. Similarly, creating a digital mobile strategy is simply not agile.

Bonus: Ask IT guys to build a few APIs and organise a hackathon to rubber-stamp your digitality (yes, it’s totally a word).

2. Digitise the present.

Digital means automating existing processes and make them available through online channels. Your digital transformation is done once you replace your paper forms with web applications. Don’t make the mistake of mapping out customer journeys, or re-imagining your interactions and relationships with your customers and the rest of the digital players. Others may be busy with creating new digital business models or building new digital ecosystems, but don’t let them distract you, you can always let them disrupt you later.

3. New technology, traditional thinking.

Digital is the cloud, AI, machine learning, the blockchain, IOT and all the other technologies in Gartner’s hype cycle. Embed these technologies in your projects as much as you can. Use machine learning to generate random numbers, use chatbots to let your customers know of your call centre number. However new the technology is, stick with the existing, tried and tested processes. Being able to stand up a new cloud instance in a matter of minutes shouldn’t mean you can access those instances without going through weeks of governance and approval processes. It is also a good practice to ineffectively deliver such technologies through a tennis game between operational silos.

4. Do it once, and do it right. Don’t experiment.

Experimenting with new solutions and business models or prototyping ideas are unnecessary risks. You cannot foresee the feature and certainly, you do not have the luxury to test and fail. Think of how your peers or execs would see it if your experiment fails. Don’t forget, culture eats strategy for breakfast; don’t be a pancake. Follow the leading company in your industry, wait for them to be successful first before you copy what they did. If you happen to be the leader, just follow this digital transformation methodology until you no longer have to carry that burden.

5. It’s a transformation project, not a cultural shift.

And just to reemphasise all that has been discussed in previous paragraphs: treat digital transformation as a project, not as a cultural and business shift. You cannot kick off any transformation without a deadline and a defined ROI. No doubt you will hear voices in the industry saying digital transformation is a continuous effort, a mindset change for the whole organisation. Simply ignore those romantics and enjoy your half-baked digital transformation or analog stagnation.

This last item concludes my methodology for successfully failing digital transformation. On a serious note, the boundaries and the impact of digital are hard to define, and, digital transformation is easier said than done. IDC predicts digital transformation spending to reach $1.7 trillion worldwide in 2018, a 42% increase from 2017. Interestingly, that is the same amount of money globally spent on the military in 2017. Yet, IDC also predicts 75% of the organisations will fail to meet their digital transformation objectives – even without the help of my successfully failing digital transformation methodology. Nevertheless, digital transformation is bound to happen in one way or another. As Greg Verdino cleverly defined in his article, “digital transformation closes the gap between what digital customers already expect and what analog businesses actually deliver”.

Read More

The Superpowers of a Technology Architect

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?

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

Design thinking process


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

What are Reference Architectures?

Greece Islands - September 2013

This is not a blog post about an emerging technology or a hot off the press IT trend, but just some notes about one of the pillars of every successful architecture work: Reference Architectures. This one explains what reference architectures are and why and how they are used in solution architectures.


Reference Architectures are template architecture blueprints for solution designing. They can also come into your way under different names, such as:

  • Reference Architecture Framework
  • Industry Reference Framework
  • Industry Model
  • Reference Model
  • Capability Model

Reference Architectures provide pre-designed architecture elements which can be further customized into a desired solution. They can be created internally by a governing body within the organisation. They are also offered by non-profit standards organizations and also by commercial solutions providers. Vendors provide reference architectures in order to support their product portfolio, and to encourage customers by guiding them on the proper usage of the offered solutions.

Types of Reference Architectures

Reference Architectures come in different scopes and contexts:

  • Industry Focused: This type of Reference Architectures provide a reference model for an industry. E.g. BIAN for the Banking industry, TM Forum Frameworx for the Telco industry.
  • Business Domain Focused: This type of Reference Architectures provide a reference model for a particular business domain. E.g. SCOR for Supply Chain Management.
  • Architecture Type Focused: This type of Reference Architectures provide a reference model for solution realization. E.g. OASIS SOA Reference Model.
  • Generic: This type of Reference Architectures provide reference models to be used across different industries. E.g. APQC Process Classification Framework.

Components of a Reference Architecture

Reference Architectures usually come as a set of linked architecture diagrams. Commonly the diagrams are supported with documents, images, posters and best practice whitepapers. Some models also provide XML schemas of the models which then can be imported into modeling and/or development tools.

Some reference architectures focus only on a particular aspect of a solution while others provide an end-to-end view. For instance, ACORD is a data architecture model for the insurance industry while IAA is an insurance industry focused model providing Business, Application, Information and Integration architectures. Below is a list of common components of a reference architecture

Architecture Type Description
Business Architecture These architectures mainly focus on the business processes. They depict a hierarchical view of the processes in a particular business area. Some also provide additional models for business terms, organizational structures, organizational skills etc.
Architecture Type Description Common Modeling Standards
Business Architecture These architectures mainly focus on the business processes. They depict a hierarchical view of the processes in a particular business area. Some also provide additional models for business terms, organizational structures, organizational skills etc. BPMN, UML Activity Diagrams, Organization Charts
Information and Data Architecture These architectures provide a hierarchical model of the information and data elements. They are also known as Common Information Models or Canonical Data/Information Model. UML Class Diagrams, Entity Relationship Diagrams
Application Architecture These architectures describe the functions and/or capabilities required from the applications to support business. UML Component Diagrams.
Integration Architecture Mostly aligned with the Information Architecture, these architectures describe interfaces to exchange information among systems. WSDL, XML Schemas

Benefits – Why Use a Reference Architecture?

Below table lists the benefits of using a reference architecture with examples.

Task Example
Solution Design You are creating a price management application for the retail industry, and you need to design a data model for your application. You can start with the ARTS Operational Data Model > Price Management reference architecture as a template saving you loads of time and potentially saves you from interminable architectural discussions as it’s an industry standard model.
Project Scoping and Roadmapping Your Telco client thinks their resource and asset management processes are inefficient. Every time they need to change a step in the process or add a new asset type to their portfolio, it takes them a significant amount of effort to implement the change. You are asked to implement an agile resource management operation for the client. You can use TM Forum Business Process Framework (a.k.a. eTOM) to understand the processes and their relationship within that particular business area. You can decide which processes to embark on and which processes to leave out of the scope. Hierarchical structure of the eTOM would also help you with right granulation of automated processes and process services.
Ensuring Interoperability For an insurance client, you are asked to integrate SAP with the new claims management system. Each system has its own data meta-model and you also know there will be new systems coming in to the integration. You decide that you will need a canonical data model to be used on the integration platform. You can use ACORD Information Model or OAGIS to build your canonical data model.
Governance Your client in the electric utilities industry has a governance body (E.g. ICC) responsible for managing SOA transformation and they have difficulties in managing service granularity, service classification and discovery, alignment to business context etc. You are asked to advise your client on the best practices on aforementioned topics. Your client can use APQC > Electric Utilies Process Classification Framework to classify their business services. Also they can use IEC 61970 Canonical Information Model to design service data objects ensuring alignment to business context.
Read More

The Return of the Digital

The Return of the Digital

As the world history repeats itself, we also see the technology repeating itself in various ways. I remember presenting an Uber 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?).

So, even the technology was repeating itself in this particular case, the difference was the other stuff going around in the IT world. I feel the same happening now with the term digital, or digitisation to be more specific. Digital is certainly not a new term. There was even a company called Digital back in 60s. The idea at that time was to bring the power of computers to business, offload the errands and calculations to CPUs and the term “digital was in the same coolness level as_time machine_and lasersaber. However, as the business and the computers evolved more and more we found new ways to use technology and the word_digital_ become a bit of old-fashioned in the era of ERPs et al.

Now digitisation comes back to business, and still with the similar promise: better customer experience with better use of technology. Again, the difference is the context. We are now living in a world where Gartner’s Nexus of Forces (a.k.a.SMAC) became a reality. Mobile apps and social networks changed customers’ expectations and behaviours as did Internet and web applications back in 90s. Customers expect to see the same swiftness and creativity from big businesses as they get from their favourite social networks. This requires businesses to upgrade the way they serve their customers and embrace an entrepreneurial spirit so they can launch innovative services to delight their customers. This also requires their internal business processes (BAU) and decision making mechanisms to keep up with this new entrepreneurial spirit. You cannot delight your customers with a fancy mobile app if your loan approval process takes a week to complete, or your collections process is not flexible enough to honour your loyal customers. Businesses should continuously investigate the ways for enhanced and leaner BAU and exploit new technologies as necessary to be able to cope with nimble start-ups. This calls for a tech-savvy business and technology professionals with strong business and customer experience acumen.

It is worthwhile repeating that true digital transformation starts with the renovation of the business culture. I would even say it's 60% culture and 40% technology based on no scientific facts.

Nevertheless, I tried to explain below how SMAC can boost digital transformation:

Mobile Applications and APIs

What can be greater for a business than to be everywhere at anytime. In 2000, I’ve attended a mobile conference in London where we spent three days discussing what could be achieved with mobile phones and their tiny screens and of course with WAP. Long story short, we achieved nothing. Only after the introduction of first iPhone things have taken a steep turn. Today users are doing stuff with their phones which have actual business value. Smart phones also triggered new application delivery and business models. Relatively small screens and users’ expectations led to simplified functionality backed by powerful backend systems. APIs became more than a technical term from 90s and evolved into business assets. APIs if managed strategically can turn your business into a platform where new businesses can be created upon. It’s now time for businesses to at least start experimenting with APIs and mobile applications, and look for the ways to unlock their data and become a citizen of the API economy.

Social Enterprise

No my friend, email will never die. But that doesn’t mean we don’t need better ways for interacting with co-workers and customers. Especially if we are keen on accelerating our internal processes, employing efficient communication channels is critical. We should have inter-company social networks not only where people chat and share cat photos but actually reach out to right people, right data and right tools. Knowledge sharing on these platforms should be endorsed and rewarded and social media in general must be considered as a serious business channel. Goes without saying, effective communications can only be achieved with the right organisation culture. If your employees are waiting more than 24 hours to get any type of response from their co-workers, or you block access to Twitter because you are scared that your employees can reveal company secrets in 140 characters, you might have more important issues to tackle on.


Cloud can help businesses in becoming digital in various forms. Elasticity is an unprecedented technologic advantage came with the cloud and cloud can also bring that elasticity to business with the right strategy. It can provide the disposable infrastructure to test your next big idea, or help you with skipping tedious purchasing, operations and maintenance processes and become more agile. It can even do better and provide affordable SaaS to accelerate your business without the hassle of the on-premise software. In fact, the benefits and possibilities are so tempting, cloud is undeniably the future of IT delivery. However TANSTAAFL and cloud is no exception. It comes with its drawbacks such as data security, inevitable integration needs and risk of vendor lock. Businesses, if they are keen to stick around long, must work on their cloud strategy and contemplate reshaping their IT to avoid cloud pitfalls. _Hint:_Grabbing that old SOA for Dummies book off the bookshelf might help.

Big Data and Big Analytics

Big Data is a broad term and has different meanings to different people. To me, it’s about having the capabilities to process huge amounts of structured and unstructured data in an acceptable and affordable fashion so that the businesses can come up with innovative solutions utilising formerly unused data. This can be a solution taking immediate actions without human intervention based on customer behaviour analytics, or the data itself opened to partners for collaborative solutions. From the technology perspective, big data spans a number of technologies such as in-memory databases, analytics tools, complex event processing, and even NoSQL as it has fundamentally reshaped the way we tackle data. All said and done, I believe the star tech of Big Data is Map/Reduceas it turned the most complicated analytic problems into issues that can be solved by throwing tens of commodity servers on to them.

Although these days SMAC is keeping the stage busy, there are some familiar faces which have been around for a while and will be even more critical for successful digital transformation. I am well aware there are tens of others but below are the most prominent ones for me:

Business Process & Case Management

Digitisation begins with accepting your BAU can do even better. In every business, there are processes depending on manual interventions, manual data input and manual controls due to disconnected systems, or systems which cannot cope with the speed of business. Business process management can help with automation of these processes and integration of the systems. Case Management can even go further and give the initiative to your employees while still enhancing BAU with process automation. It is up to businesses to use these capabilities wisely. First step is to re-visit internal processes and investigate the ways to uplift them from a better customer experience, efficiency and effectiveness perspective. Each business at some point ends up with a soup of systems with overlapping capabilities and with overcomplicated, faulty ways of working habits developed over the years. It is the time to start the transformation with process excellence and make it digital with BPM and Case Management.

Enterprise Architecture

No strategy will do any good unless planned and executed properly. First off, you will need inputs from across the organisation to feed your strategy. You will also need to understand the impacts at different levels and estimate the effort required for change. Then you will need to make sure your strategic plan is constructed with the right scope and the governance metrics are defined correctly to measure the performance of the implementation. A good Enterprise Architecture is a great tool for strategic management as it reveals the interdependencies between strategy, management, operations and technology. It also links static artefacts to dynamic components and the current state to future state. EA is a must for defining and implementing digital transformation. It can help you to pinpoint and prioritise the areas where digitisation can have the largest impact. It can also help you with planning and scoping the change. With EA, you can define improvement chains starting from customer facing applications and services, going down to operational processes, and then to systems.

Although many are still not too clear on what digitisation exactly means, it is poised to be the next big thing in business and technology. We will read more articles and blog posts like this one on digitisation and see vendors come up with (or just re-package) products for successful digital transformation. Digital has its charms as well as pitfalls, in any case, it is going to be exciting times and the change will be phenomenal.

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