erwin, Inc.

So, you are in the middle of a modeling session, and something you are doing triggers a question in your mind. What are the resources to get answers to those questions, and what resource is best to use for which situation?

Greetings and Happy New Year to you all!

Walk before you run. We’ve heard it a million times, referencing almost as many different disciplines. Yet as time is limited, it’s often human nature to want to get things done quickly. However, much like our first steps, building a successful Enterprise Architecture practice is a process worked on and developed over time.

This is where a maturity model comes in. Maturity models are employed as a means for businesses to evaluate their current position, and therefore, better understand when it’s the right time to move forward and how to do so.

At the risk of a metaphor overstaying it’s welcome, consider this: buying your infant an expensive pair of runner’s shoes and expecting them to sprint is a misguided presumption at the very least. With the child clearly not ready to utilize them, there’s absolutely no way to justify the cost. You’re better off with a pair that are fit for purpose with the knowledge that they will be outgrown.

Maturity model use in enterprise architecture

Enterprise architecture (EA) can be viewed in the same light. If your enterprise architecture practice is newly established – the type of set-up that’s focused on reacting to issues as they arrive – you shouldn’t expect the team to immediately start delivering the work more associated with vanguard enterprise architects, who’re more focused on thinking forward, planning and innovating.

A maturity model is essentially a survey based framework, purposed for assessing IT capabilities. Capabilities including but not limited to operational efficiency and effectiveness. In short, the IT leaders in an organization complete a survey, and are awarded a score based on their answers.

However, the maturity model itself isn’t where organizations will find its value. It’s the knowledge gained from an organizations current position and insight from the model and it’s suggestions that gives the model its worth. Businesses can use this information to influence development roadmaps for their enterprise architecture practices, to better them going forward.

Gartner’s own EA maturity model generates generic, yet prescient suggestions for developing a practice. These suggestions are the cumulative understanding and judgment of some of the industry’s most trusted analysts.

However, organizations should tailor their development plans to themselves, as the nuances of their individual experience will rely on the organizations own business outcomes.

Perhaps the biggest benefit of a maturity model for the EA practice, is that it can help you better identify the right time to go bimodal, establish Vanguard Enterprise Architect roles or expand the team. This is important, as the current industry trajectory indicates that bimodal approaches to IT will be increasingly essential as digital business continues to expand across markets.

The different levels of the enterprise architecture maturity model

Gartner’s is by no means the only maturity model in the discipline. However, due to Gartner’s prevalence and status as an industry trusted source of analysis, their model is a fine point of focus for this discussion.

Their maturity model identifies five different levels of maturity within enterprise architecture practices. Ranging from an enterprise architecture structure that is “Non-Existent”, to one that is “Ubiquitous.”

They breakdown the five levels as such:

• Level 1: Nonexistent — As it sounds.
  In this instance, enterprise architecture either hasn’t existed until this point, or is in its very early stages of implementation, and any enterprise architecture work that has been done, was almost certainly informal and off cuff.
• Level 2: Reactive — In this instance, an enterprise architecture practice does exist, and is officially recognized by the organization. However, the nature of the practice is one of response, rather than preemptive planning and action. Because of this, work is still on an ad-hoc or off cuff basis, and can usually only promise short term fixes.
• Level 3: Functioning — At this point, an enterprise architecture practice is now operating with business outcomes in mind. The Foundational Enterprise Architect is often well represented here. However, the organization isn’t necessarily prepared for a truly bi-modal EA set up, and might struggle with balance when bringing in some of the more Vanguard EA responsibilities into the fold.
• Level 4: Integrated — At this stage, the enterprise architecture practice is delivering value, and consistently so. Vanguard EAs are clearly established and so the business can adopt a ‘true’ bimodal approach to its operations. This is where organizations should aim to reach at a minimum as here, an organization is delivering on business outcomes.
• Level 5: Ubiquitous — Here, enterprise architectures success has a trickle down effect across the organization. EA becomes a natural way of working and the principles behind the discipline are widely adopted.

The changing role of Enterprise Architects

Along the EA practice maturity journey, the enterprise architecture team tends to refocus at the different stages. Initially, the practices’ main focus is providing guidance – if you’re familiar with bimodal IT (you should be) you’ll know that this corresponds with ‘Mode 1’. Here enterprise architecture is predominantly concerned with answering specific questions about maximizing efficiency in processes, reducing complexities and helping to steer and implement development decisions.

The practice then moves towards a new focus, concentrating on delivering business outcomes. Enterprise Architects are responsible for laying out the structure behind the business strategy, and working towards and finding the business outcomes behind said strategy. At this point, EAs are also responsible for ensuring IT in general, stays aligned with the wider business.

Lastly, an enterprise architecture practice will occupy the space it arguably needs to be today. Practices are now tasked with supporting digital business – a concept that occupies a mass of consumer markets, and continues to infiltrate more. This is where enterprise architecture demands innovation, and why innovation management capable EA tools are a smart and valuable investment. Enterprise Architects are now responsible for creating new business opportunities, not just support in reaching their outcomes. This demands a different type of Enterprise Architect, and the introduction of a new ‘Mode’ (Mode 2) into the way the practice operates.

In each of these transitions, the previous is built upon rather than forgotten. This is where bimodal IT is so important when navigating the digital business environment. A mature enterprise architecture practice demands responsibilities for both ensuring “business as usual” and delivering business innovations.

Upgrading doesn’t have to be a difficult experience, but it does require planning. If you model your “as is” environment and your “to be” environment, prepare a written plan to get from A to B, review all necessary documentation, and then perform a dry run in a test environment, you can make a smooth migration of your production environment with minimal  disruption to your production environment. Let’s talk about the process in more detail.

Coasting and jogging was okay when IT was an agent of support. Infact, the intermediate pacing was ideal for the job, that required teams to operate and maintain mission-critical legacy infrastructure. But since the ascent of digital business, IT teams are now front and center and have garnered a new onus to innovate – and innovation is a sprint.

The problem is, IT’s old guard is far from retired and the support cogs still need to turn. Yet expecting a legacy/traditional IT team to take up the mantel of ‘new IT,’ is akin to substituting chalk for cheese at a dinner party for mice.

Enter bimodal. The technology equivalent of having your cake and eating it too. Bimodal IT is a Gartner-coined term and IT practice that fundamentally acknowledges the separation between new and old IT.

Bimodal IT – A Jog vs. A Sprint

The two (bi) modes couldn’t be more different – Mode 1 is more suited to the traditional, emphasizing scalability, efficiency, safety and accuracy. Whereas mode 2 is primed for non-sequential and often ad-hoc, emphasizing agility and speed.

A well executed bimodal IT practice seeks to blur the lines between the antitheses, and create a harmony between the teams.

Why Bimodal?

Industry adoption of bimodal practices is already evident. In a 2015 study, Gartner spoke to CIOs to determine their spending priorities for 2016. (Further reading: for CIOs 2016 concerns, click here)

They found that from a list of twelve, mode 2 occupied half of the list, and of the top three, mode 2 accounted for the number one and third spots respectively.

But adopting bimodal shouldn’t be solely down to industry trends – your business should adopt the practice on its own merit.

The reason being, is because bimodal is fundamentally intertwined with the DevOps and Agile Development philosophies – coupling rapid, evolutionary application and service development with IT operations and maintenance to deliver products on a rapid release cycle. This is an idea that resonates with organizations both big and small, as organizations across the board are already familiar with concepts such as Agile and Lean.

Implications of moving to Bimodal IT

This table shows the implications of IT moving to a bimodal setup. Remember, the overarching goal of Mode 1 is reliability, supporting the business critical applications, whilst the goal of Mode 2 is to enable the business and IT to act with agility in response to new opportunities and challenges.

Why decouple mode 1 and 2 in this way? Well, legacy systems are typically responsible for an organization’s most critical processes – managing critical data – and are valued for their reliability, availability and security. With these “brownfield” environments, it is far too complex and risky to experiment with innovative new ideas and introduce cloud services.

Where does Enterprise Architecture fit in?

Enterprise Architecture (EA) helps in several key ways. Firstly, in identifying your Mode 1 and Mode 2 assets; but also in improving communication throughout the organization, building accurate models and roadmaps, understanding the impact of change and identifying the real costs.

Additionally, EA helps in increasing project success and reliability, standardizing business and IT assets, and in traceability of objectives to projects for increased visibility.

It’s nearly impossible to experiment with innovative application development tools and cloud services on brownfield environments: the IT equivalent of spaghetti code, a byzantine tangle of systems, software and support personnel.

Instead, the bimodal approach identifies areas where IT has less to lose, but large potential gains, by using iterative development, new software tools and public cloud services. Many times, even the business model for an emergent IT service isn’t well understood and subject to rapid, market- and user-driven change. Here, it’s far better to have development and IT operations’ processes with the smallest possible overhead.

While the tortoise wins the slow, steady marathons, the hare is far better on an unpredictable course full of twists and turns.

Defining Mode 1 dependencies

To understand Mode 1 dependencies in your enterprise architecture, you should ask yourself questions such as:

• What are the key systems?
• What affect do they have on key processes?
• Which locations are impacted?
• Which organizations and roles are responsible?
• What data is affected?
• Is there any technology required?
• Which business capabilities are affected?

One way to identify Mode 1 EA concepts is by querying relevant attributes. For example: all Business Processes that have high criticality AND all Applications that are supporting critical business processes. Applying this type of query to your EA models helps you visualize the assets and their relationships.

Identify Mode 2 candidates

To identify Mode 2 assets in your enterprise architecture you should identify concepts with low to medium Risk attributes, and high or relatively high Organizational Value attributes.

Running this query on your architecture models helps you visualize assets that fit Mode 2 IT approach. An example of this is shown below:

Different viewpoints, such as circular diagrams, can then help you better understand the relationships between your concepts.

Introducing an Innovation Management process

A managed innovation process feeding into your enterprise architecture workstreams acts as a mechanism for discovering the opportunities associated with Mode 2 assets. You can see in this framework, new ideas and initiatives (in the upper-left) relate to overall approach.

Innovation Goals and Campaigns

Campaigns are an effective tool in focusing innovation/ideation efforts around an objective or goal. But how do you know where to focus first?

Our recommended approach is to target the “low hanging fruit” that you’ve identified by classifying Mode 2 assets. These efforts can then be aligned to the CIO’s goals with the use of Business Capability Maps and Motivation models.

In this example, you can see that the concept called Claim Management is both a Mode 2 technology priority and is connected on the Motivation view.

In Summary

A strategic planning lifecycle can support a bimodal approach to enterprise architecture. Businesses should use traditional enterprise architecture to identify Mode 1 dependencies and Mode 2 dependencies, answering questions such as: “What attributes make Mode 1 assets for you?”

Additionally, organizations should command innovation management to look at opportunities for Mode 2 assets. This way, business leaders can discover and focus innovation on areas of the business/architecture that carry less risk but considerable value.

A firm grasp of these principles can be the difference in adopting a truly bimodal approach, readying your business for the present market, whilst future proofing processes by enabling a truly Agile method of responding to change.

You may have heard the term floating around. You may have even tried to adopt it already.

In any case, bimodal approaches to IT are steadily becoming the new normal, as new onus is placed on IT teams to be the forefront of business revolution, innovation and progression, rather than ‘just support’.

So what is bimodal IT?

Well if you go by Dave Aron of Gartner’s definition, it’s something to do with Samurais and Ninjas – which sounds highly impractical in a modern setting. Especially in business. But Aron may actually be on to something.

“Bimodal IT is not two-speed,” he said. “It’s about Samurais and ninjas. You don’t want an army of ninjas because it would be too chaotic, and you don’t want your innovation done by Samurais because it would be too boring. The end game is to recognize who your Samurais are and who are your ninjas and have them working together.”

Ninjas and Samurais rarely let me down in a metaphor, but in case you’re still not following, bimodal IT is all about recognizing that IT has grown.

It views IT as having two recognizable arms, or types. Type 1 being the traditional, stability and reducing overheads focused arm, while Type 2 takes up the mantle of modern IT expectations in agile organization and a focus on innovation, time-to-market and alignment – all among common the most common CIO struggles.

Bimodal IT is the recognition that IT is no longer a single purposed tool of support, and that it’s grown into a division of business with wider reaching responsibilities. It’s not two-speeds, it’s multi-pronged. Two business arms working separately, yet in tandem.

Bimodal IT in Enterprise Architecture

Today’s Enterprise Architects reflect the duality of bimodal IT. They fall into two identities, the foundational enterprise architects (EA) and the vanguard. The foundational EAs handle enterprise technology maintenance, and the vanguards drive innovation and tackle technology disruptions as they come. Sound familiar?

The vanguard evolution is largely down to the much increased weight on technology and digital business as a whole. This new market demands agility, innovation and the other vanguard EA attributes as fundamental system requirements.

So where does SaaS come in?

Well first of all, what is SaaS? Despite its homonymity, SaaS isn’t about snappy fingers and fierce attitudes. It stands for ‘Software as a Service,’ and as Gartner defines it, is “software that is owned, delivered and managed remotely by one or more providers.

“The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at any time on a pay-for-use basis or as a subscription based on use metrics.”

In essence, SaaS is a modern take on leasing software, that shakes off the installation costs, upkeep costs, and other headaches (that often cost), associated with locally stored software.

Instead of running locally, stored on on-site hard drives and discs, SaaS systems operate in the cloud.

But much like new-age IT, SaaS isn’t just about reducing overheads – it’s also a key enabler in business agility.  The hosted nature means the relevant parties can all be updated in real-time, and acts as a fantastic facilitator to dialogue around suggestions and queries. This collaboration is crucial in being able to adjust, pivot and realign quickly in the face of disruption.

Enterprise Architects find SaaS particularly useful for these reasons. The ease of collaboratively modeling, roadmapping and effortless communications are positives that can’t be ignored.

All of this equates to a model that’s not only ‘agility-capable‘, but primed for such reasons, making it a perfect harmony to EAs new song.

SaaSy Bimodal IT

For many businesses, the SaaSy approach to IT is the only way to facilitate adopting bimodal IT. Many small-to-medium sized businesses (SMBs) don’t have the resources to action a truly bimodal approach in house. Between maintaining systems, and other tasks typical of traditional samurai IT, there simply isn’t enough time in the day to be ninja.

A transition to SaaS would transfer much of the burden of maintaining systems to a third party, and leave space for IT departments to work on revolutionizing, innovating and improving business operations, a staple of efficient bimodal IT.

This is great for SMBs, as they don’t have to worry about stretching resources, or expanding the IT team. Instead, they can simply repurpose their current IT team, into the Type 2 IT professionals of modern business.

We’re already seeing businesses catch on to this principle, with an industry swing towards cloud based solutions being backed up by solid research.

A Dimension Data-led study found that on site data storage is “fading into the category of legacy technology.” One of the reasons suggested, was the advances in quality and stability, making the cloud a more appealing option than it might have been in the past. But also cited, and perhaps more importantly, was setting up and maintaining a cloud system has a “much lower cost.”

Despite the data, and relatively transparent benefits – including but not limited to enabling bimodal IT and saving money – there’s still an air of concern surrounding SaaS and the ‘Cloud’ in some corners. The former certainly isn’t helped by its ‘Shadowy’ epithet – SaaS has been dubbed Shadow IT by industry insiders.

It implies ill, and well… Shadowy practices. The naming can be deemed unfortunate, though, as the wide adoption of the SaaS label shows the industry trying to shake the moniker.

That’s because Shadow IT isn’t, and has never been an Emporer Palpatine figure, pulling strings in the background as a nefarious, classical composer. Rather it’s ‘Shadowy’ in that it can exist in the background, without any thought. And when it comes to an organization’s systems, that’s really how it’s supposed to be.

It’s key to repurposing IT departments to function in this modern era. If your IT department’s only function is support, when many of the most profitable modern businesses not only prioritize IT, but actually base their core functions on tech, you’re going to fall behind.

And these are precisely the pains that SaaS can effectively iron out. Time and financial costs of maintaining systems are taken out of the equation, so what’s left over, can get the intention that it not only deserves, but that the current market demands.

Whether it’s producing and selling technology, or giving consumers new and easier ways to interact with the business and its various services, IT is front and center now, and should be valued as such.

Go SaaS, and your old, boring, samurai, suddenly have that extra wriggle room to be ninja.

Unless your head is buried in the sand, it is likely that you have heard talk about 32-bit and/or 64-bit software, processors, or operating systems. Perhaps, even all three. I’m sure that technophiles (e.g., “geeks”) are comfortable with this discussion, but what about “regular” computer users? I am sure many may have an idea what the discussion is all about; however, I suspect that there might be a lack of subject clarity – and more importantly, a lack of knowledge regarding the implications of 64-bit versus 32-bit. My goal is to shed some light on this topic in order to help users better understand this topic.