WHAT IS AGILE ENTERPRISE ARCHITECTURE?
(AND WHY SHOULD YOU CARE)

In light of the work and results we have delivered to our clients over the past year, today we are introducing a new blog series focused on the impact of successful and strategic Enterprise Architecture.

Being successful in the current business landscape demands agility, a deep focus on customer value, and the ability to build and deliver adaptive strategies. 

If you haven’t considered the way these trends are affecting enterprise architecture (EA), you’re already behind. 

In this article, we’ll explore a new paradigm: agile enterprise architecture. But before we explain the value of this approach, it’s critical to get on the same page about a few core concepts. 

What is enterprise architecture?

Essentially, enterprise architecture is the practice of understanding and documenting components of an enterprise — and the relationships between these components — in order to improve strategic planning and decision making. 

The practice of enterprise architecture encompasses discovery (what does the enterprise have now and what will they need in the future?), design (what’s the best way for the enterprise to achieve its goals?), implementation (how do we put this plan into action?), and documentation (how do we synthesize this information in a useful way?). 

Enterprise architecture is usually focused on information technology and the relationship between IT and business goals. One major goal of EA is to reduce technology debt, a term used to describe the ongoing costs associated with hastily chosen IT solutions (as opposed to those considered in the context of a long-term plan). 

What is agile?

The agile methodology is an approach to the development of products or systems that emphasizes adaptation, evolution, and flexibility. 

The first use of the agile methodology was in software development. However, the spirit of agile — as described in The Agile Manifesto — can be applied to many different practice areas, including enterprise architecture. Frameworks like SAFe^® provide guidance for applying these principles to different parts of the business. 

To boil it down to one key element, an agile approach values responding to change over following a plan, delivering incremental value throughout the entire improvement process. In other words, it is an iterative, ride-along approach rather than a prescriptive, point-in-time approach. Value is created along the journey, instead of being solely located at some distant destination. 

The trouble with traditional enterprise architecture

What does EA look like in reality?

Most often, enterprise architecture is the responsibility of one individual or a small team within an organization, or an additional role added to the many on an already overburdened leader. They conduct point-in-time exercises and apply EA “best practices,” which are typically academic in nature rather than drawn from contextualized real-world experience. 

The outcome of these exercises is usually a monolithic document that’s difficult to apply to day-to-day decision making. This document purports to “solve” the enterprise’s technology problems, but too often ignores the fact that every solution has a lifecycle, and that the usefulness of solutions changes over time. 

Because traditional enterprise architecture plans don’t flex and adapt, the technology solutions proposed by the EA team tend to become disconnected from the strategic pulse of the business. These legacy approaches structurally ignore the fact that what you know now is almost invariably going to be significantly different than what you’ll know later on. 

As a result, despite being expected to own the long-term technology strategy for the enterprise, EA teams often slide down the slippery slope towards being perennial meeting floaters, sitting on the sidelines of decisions rather than contributing real value.

What is agile enterprise architecture?

Agile enterprise architecture is a new approach to EA developed by The Gunter Group. Agile EA applies the principles of the agile methodology to enterprise architecture in order to improve business outcomes.

Agile EA focuses on iteration and continuous improvement. In this approach, the job of an enterprise architect is not just to deliver a roadmap — it’s to ride along with the roadmap, continuously closing the gap between the plan and reality as it unfolds. 

In addition, a major goal of agile EA is to create a set of architectural patterns that help define business problems and orchestrate their solutions. Agile EA decenters specific technology recommendations in favor of methods and frameworks for finding the right solution in any situation. 

To put it another way, an agile enterprise architect understands that “owning” the long-term technology plan for an organization is not a sustainable responsibility. Instead, agile EA focuses on enabling internal teams to generate their own solutions to complex problems in alignment with broader strategic goals. 

Agile EA dispenses with outdated and ineffective elements of traditional enterprise architecture practices. Whereas traditional EA is academic, agile EA is pragmatic. Whereas traditional EA is prescriptive, agile EA is adaptive. Whereas traditional EA often becomes decoupled from business strategy, agile EA is solely focused on the ways technology enables business outcomes. 

Ultimately, successfully practicing agile enterprise architecture ensures the organization has the technology runway it needs to achieve its strategic goals. 

Enterprise architecture as a service (EAaaS)

One manifestation of agile enterprise architecture is enterprise architecture as a service (EAaaS). As opposed to project-based consultants who are rarely around long enough to see the execution of their proposed roadmaps, EAaaS provides ongoing support in a scalable subscription format. 

EAaaS can augment or transform in-house EA teams. There are several advantages to this approach, including:

• Knowledge: EAaaS provides access to a broad base of skills that are constantly being honed in real-world environments
• Change: a third-party team can act as a change agent, helping organizations overcome internal roadblocks
• Scalability: EAaaS can be scaled up or down according to current business needs (for example, increasing service following M&A)
• Cost: The Gunter Group’s EAaaS approach will typically cost less than the full-time salaries of an in-house team

Through enterprise architecture as a service, The Gunter Group has the ability to transform an ineffective, impractical enterprise architecture function into an agile driver of positive change. 

A new era in enterprise architecture

We believe that agile enterprise architecture — which is best realized through EAaaS — represents a dramatic improvement over the status quo. 

More than that, however, we view the shift to this approach as a necessary component of a successful enterprise. 

The old models and best practices of enterprise architecture were developed in a different era. They were not built to handle the strain of the rapid growth and change made necessary by the pace of and competition in the modern landscape.

However, by treating your EA capability as a strategic enabler rather than a tactical function, you will unlock business agility, customer value, and long-term success. 

Agility is the hallmark of today’s most successful businesses — and you simply cannot have an agile enterprise without agile enterprise architecture. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

AGILE & THE BATTLE FOR BETTER BUSINESS

Agile is a solved problem, in the tech world. In software development environments, it’s now a staple. You would struggle to find a single development team or technology project that isn’t using an agile framework to plan and execute their work. The idea has long passed from experimental to adoption; it has saturated the market.

Little proof is needed for this claim of complete saturation. Just look at the list of certification-ready agile methods: SAFe, Scrum, Crystal, DSDM, Feature-Driven Dev, ASD, Lean Software Dev, Disciplined Agile, RAD. Beyond the certifications you’ll find (often decades old) schools of thought around Wagile, eXtreme Programming, and others. When you can certify yourself in a handful of different frameworks around the same concept, then it’s safe to say that the school of thought is here to stay.

Outside of tech, though, the potential of agile is still largely unrealized. Waterfall methodology is still the dominant approach to project and product management. At the Gunter Group, we feel this is a missed opportunity. The practice and benefits of agile should no longer be the sole domain of nerds. 

The Coming Revolution

Agile has revolutionized development, or rather, agile is the response to development’s demand for revolution. Waterfall was the child of the uniquely meandering progress of early software projects. Early development borrowed from manufacturing, aerospace, and defense methodologies of the time, and depended on long runways for delivery (and even occasionally relied on physical manufacturing processes).

However, as software leapt forward, the waterfall methods of old failed to serve the split-second pivots required by the go-to-market environment of modern technology. Software development demanded a new kind of organization, one as iterative and quickly-changing as the 1’s and 0’s upon which it was built. From this need, agile was born.

It is a mistake, however, to limit agile to the tech environs of its birth. There is nothing about agile that is necessarily specific to software development. We repeat: there is nothing about agile that is specific to software development. It is a framework that has application well beyond its homeland.

A renaissance is before us. Agile has yet to have as meteoric an effect on the broader business world as it has in all-things-tech, but this change is on the horizon. In this article, we will explore several simple means for the application of agile in non-tech environments.

This article is for agile practitioners. It is also for anyone else who works in a world of projects and output-oriented teams. That means everyone. Yes, you read that right: everyone. (Even construction has room for agile. There are certainly limits to the application, as failing fast in that landscape could be catastrophic. Construction is a mature industry with many unique frameworks for success, but the concepts of agile are still applicable in creative ways. Design iteration, proposing and awarding subcontractors, and daily standups with subs might be areas for immediate agile-inspired growth).

Tried and true in the tech-focused backbone of our ever-changing world, the revolution of iterative, cross-functional, self-forming teams will ripple through organizations and markets of all kinds. The thoughts below are intended to give you a leg-up in this revolution, to find yourself ahead of the curve in the battle for better business.

The Business Cycle & Agile: An On-Again, Off-Again Relationship

Agile has a place in the business cycle, but only one place. The picture below illustrates this (a notable exception to this limitation can be found in the SAFe framework, which has made progress in utilizing agile in a broader business context). Agile is often embraced by a development team or manufacturing process, but everything upstream and downstream from these teams still think of their work in terms of waterfall. As the landmark book The Lean Startup explains in detail, this often results in products reaching the market after months or years of investment without validation that the product is even needed.

This can be fixed. At TGG, we have seen successes and failures with clients attempting to embrace agile methods. There is no one right or wrong way to embrace agile, but we have seen some general activities or mindsets prevail over others.

Below is a list of high-level considerations you should keep in mind if you are interested in adopting agile in your non-tech team:

Don’t Do Agile for Agile’s Sake: It can be easy for a leader to say, “It works for the Unicorns so it should work for us.” As a result, agile or lean Centers of Excellence sprout up in organizations that are not ready or willing to embrace these methods. Agile only works when a team understands why they are doing it and are engaged in the method in a way that adds value. It is all about developing business agility and driving value to the customer—not just about “doing” agile.  

Find the WHY (Value Added): People are more willing to change when they understand why a particular change will benefit them. This is universally true, and is a fundamental concept that drives all successful change efforts. When accompanying a team that is new to agile, break the component parts down into WHYs that demonstrate the value added by an agile element. More on this below.

Use a Light Touch: For teams that have been thinking in terms of waterfall timelines and years-long delivery plans, agile is not intuitive. This is even harder for teams that don’t operate in a project environment, such as operations, finance, or HR. It is uncomfortable for someone new to agile to imagine releasing their work before it is “completely done.” For these people, adopting agile represents a culture change. Use a light touch, and embrace change management best practices. Educate on the value of embracing agile ceremonies and artifacts (see Point #2), and give them time to adjust to a new work culture.

Think About Slicing Small: You might think that the key difference between waterfall and agile is the speed of the work. However, this doesn’t quite capture the power of agile methods. Agile teams don’t work faster—they work smaller. Sprints are only successful when a team can break their work into smaller chunks that can be accomplished, reviewed, and delivered to customers in a matter of weeks. When looking to adopt agile in your non-tech team, this can be one of the hardest yet most rewarding mindsets to shift. Ask yourself the question: “What can we complete this month and deliver to our consumers?” 

Start with Standups and Retrospectives: When in doubt, the easiest place to start with agile adoption is with standups and retrospectives. Gather your team together so everyone can give a 30 second status update and share any blockers. Encourage recognitions, because they actually do boost engagement. Periodically bring everyone together to reflect on the way they work, and encourage them to think creatively about small changes they can make to boost productivity or morale. These rituals are baked into agile systems but are often overlooked in the recipes of other structures. They are ceremonies that are simple to implement (their WHYs are easy to understand), and they immediately add value to your team.

Find the WHY: Representing the Value Added by Elements of Agile

In tech, it is easy to take agile for granted. There is little need to investigate why that is the case. Dev teams embrace the frameworks without the need to justify why. Tech simply trusts the efficacy of the model.

Non-tech environments are more skeptical, however. Business units accept the place of agile in their organization’s tech division, because the quality and turnaround of their tech solutions are desirable outcomes. But a chasm exists, an us versus them void between tech and business, in which each realm agrees to the ways of the other without cross-pollination. “Agile works for IT,” says the non-IT department, “but we will carry on as we always have.” 

When making the crossover from tech to non-tech, asking WHY is essential. When making the case for an agile adoption in a non-tech environment, it is not enough to know THAT agile works; you also have to understand WHY it works. 

The core concept of this article is this: by breaking down the framework into a series of WHYs, you are able to build a business case for its adoption.

In Search of WHY

Before diving into case studies, we’ll pause to give a couple brief examples of how to find WHYs. First, we’ll give an example of finding a WHY, and then we’ll observe an organization that has used this WHY thinking approach to maximize the benefit of agile enterprise-wide.

We’ll start with an example of a WHY. Any agilist knows of two basic roles that tend to show up in any agile framework: the Scrum Master and the Product Owner. But why are these roles so valuable? In short, they capture a tension that exists in every project: throughput versus quality. 

The Product Owner represents the customer. He or she is ultimately accountable for the product that hits the market. They massage the backlog, prioritize features, and vouch for the throughput and objectives of the customer. The Scrum Master, on the other hand, is a servant to the team. He or she is responsible for maximizing the value of the team’s work by removing impediments and maintaining focus. 

In every project, there is a tension between speed and quality, and often these elements are at odds. Teams have to choose between the speed or quality of their throughput. The roles of the Product Owner and Scrum Master capture this tension, striking a balance that delivers a timely, quality product. 

Here’s the WHY: agile purposefully creates this tension. The Product Owner advocates for the deliverable; the Scrum Master advocates for the team. There is no consensus without dissent, and the dissent built into the agile framework ensures a consensus between the competing demands of immediacy and quality. 

You’ll notice, in this example, that the WHY is subtle. It simply looks at two roles and understands the purpose for each of them, both individually and together. But their purpose, the WHY, is powerful. Maintaining the tension between throughput and quality ensures that an agile team continuously delivers a product that is valuable. 

There are many examples of organizations finding the WHYs, but a fantastic example can be found in the way Spotify approaches an agile culture. Spotify, a tech company, started from the assumption that agile adds value. But they also embraced a key mindset: rules are a good start, but let’s break them when needed. This led Spotify to match its needs (autonomous squads, short term goals, and an enterprise-wide holistic product strategy) to the WHYs of agile (throughput vs quality, flexibility, consistency, autonomy, alignment) to create a truly unique structure of tribes, squads, chapters, and guilds.

These unique, overlapping structures don’t conform to any particular agile method, but point to the WHYs of agile as necessary predecessors. The result: a nimble organization and healthy culture that keeps pace with the ruthless, fast-paced competition of streaming music solutions.

Agile in Business: Case Studies

So far, we have discussed the concept of embracing agile elements in non-tech teams. Let’s look at a few examples of this concept in action.

The Lean Startup – Laundry Services in India

A current popular expression of these concepts can be found in the book, The Lean Startup by Eric Ries. Over the course of 300 pages, Ries walks the reader through a home-grown approach to agile adoption grounded in decades of direct and indirect (consulting) experience with entrepreneurs and startups.

Core principles of The Lean Startup include small slicing vision into minimum prototypes, testing those prototypes early and often, validating assumptions, and promoting a culture of constant adaptation and growth. These agile-adjacent methods are all implemented without any of the typical agile ceremonies or artifacts.

There are dozens of case studies in the book that demonstrate the WHYs in action. One example comes from a laundry service launched in India: Village Laundry Service (VLS). In 2009, VLS was poised to launch a low-cost modest-return laundry service in a virtually untapped market in India.

The company, however, paused to create small-scale experiments to validate product assumptions and zero-in on specific customer needs. They embraced a model of iterative testing and adaptation that allowed them to target a rollout that was specifically tailored to customer needs. This meant that, once scaled, VLS was sure that they were mass-producing a product that customers would actually buy.

National Insurance Provider – Accounting Team “Scrum”

An insurance provider engaged us to assist with an ERP implementation that would replace the general ledger that accounted for tens of billions of dollars in managed assets and revenues. In the organization, there was a Lean Center of Excellence that had been advocating for agile ceremonies across the organization for several years. However, the accounting department had not yet adopted any of these elements. Early in the project, the team decided to organize themselves into a scrum team, with all the usual ceremonies and artifacts.

Initially, the transition was difficult. The team consisted of financial analysts and operations managers, and no one had project experience (let alone a knowledge of scrum). The “scrum team” was also larger than recommended, with more than 15 people.

Over time, the team used the ceremonies to break down their activities into a series of WHYs. Daily standups helped illuminate blockers and inefficiencies, and sprint retrospectives allowed the team to reflect on what was working and what wasn’t. Before long, the team developed a rhythm to their work and were able to break out the scope into smaller slices that more efficiently made use of their resources. Additionally, they were able to quickly track and validate decisions made about the product, which allowed for quicker pivots that better met the needs of their internal stakeholders.

HR Job Posting – Introducing Small-Slicing to Recruiting

On November 20, 2019, TGG’s Tech Services Lead Matt Jamison presented to AgilePDX on the topic of adopting agile elements in non-development teams. To illustrate his ideas, he shared an example of applying agile to talent acquisition in an HR department, with regard to staffing practices. 

The Problem Statement: the struggle to find and hire talented resources presents a series of constant hurdles. Even without complications, it is difficult to sort through the tides of resumes to find individuals who have the professional and cultural acumen needed for a particular situation. 

But hiring does not occur in a vacuum, and complicating factors abound. Hiring teams struggle to match job postings to the continuously changing needs of their organization. Market factors like shifting regulations, emerging fields, and competitive innovation require constant adaptation to who or what an organization needs on their teams. On top of this, the company mission is regularly transitioning due to adaptations from corporate strategy and new products. 

When hiring for a team, there is a need for agility. Despite this, overworked recruiters are often incapable of the continuous change that would empower them to hire better, faster, and smarter. Poll HR professionals and you will likely hear the same thing, “I’m not getting the right talent. It takes too long to get talent. How do I assess the growth of employees and allow for advancement? I don’t respond quickly enough to changes in my organization and market.”

Enter the Agile WHYs: how would an HR team look to agile to address some of their struggles? Start with the problems: 

– There is too much to change and not enough time to adapt
– Changes in job descriptions require a lengthy approval process

Looking at these problems, several agile WHYs start to jump out in response:

– Vertical slicing deliverables into bite-sized stories
– Sprint structure allows for near-term pivots on vertical slices
– Empowering team members to problem solve allows for quicker creative solutions
– Iteration on pain points or strengths allows for continuous improvement

An HR team embracing these WHYs wouldn’t have to embrace a full scrum adoption to realize their benefit. They could small-slice a job description, looking at components of a specific description instead of the whole thing. They could explore ways that recruiters could update parts of job descriptions in a quicker manner without needing full bureaucratic and legal review involved with a new job post. They could collect user stories from teams with upcoming resourcing needs instead of a list of qualifications and specific experience, empowering recruiters to be more creative in finding the right fit. 

By embracing the WHYs of agile, teams can borrow the best parts of the methods and ceremonies to foster agility. And by doing so, they are living up to the core principles of agile, putting individuals and interactions before processes and tools.

We want to close this paper by reiterating a key point that is foundational to adopting agile in new environments: don’t do agile for agile’s sake. If either managers or direct reports fail to understand the reason why they are making a change, then that change is destined to fail. Do not embrace agile just because it’s trending in high-dollar markets. 

There are good reasons for the successful outcomes of agile—a successful adoption requires an understanding of these reasons first. After witnessing successes and failures in the market around us, we firmly believe that a team must understand the WHYs of embracing agile methods before jumping in. 

More about Matt Jamison:
Matt is an experienced solutions architect with a results-oriented understanding of the intersection between reality and architectural theory. He has the ability to plan, develop, and implement large-scale projects while maintaining impeccable attention to detail. With 20 years of functional information technology experience, Matt has end-to-end IT knowledge from layer 1 networking to application API interaction. An expert in mapping technology solutions to business needs, Matt is also able to conform to required regulations while maintaining IT best practices. Matt’s experience spans multiple industries, including healthcare, telecommunications, and security and software. He is an AWS Certified Solutions Architect. Outside of work, Matt enjoys the outdoors and all things bike-related.

More about Josh Bathon:
Josh is a creative problem solver with experience in project management and process improvement. Josh thrives in situations that challenge him to learn quickly and adapt to new environments. Leveraging his unique background in seminary formation, Josh brings emotional intelligence and self-knowledge to his interactions to build lasting, goal-oriented relationships. Josh has experience in healthcare IT, primary education administration, and non-profit service, environments in which he has developed a team-oriented leadership style geared toward high-performance outcomes. Josh holds a Bachelors in Philosophy and History from the University of Notre Dame. When he’s not working, Josh loves to read fiction and philosophy, as well as explore the cuisine and quirks of the Portland Area with his wife.

ARTIFICIAL INTELLIGENCE & YOUR BUSINESS: 3 THINGS TO KNOW

For Starters: This is Not Skynet

Artificial intelligence is all around you. You have been using it for a while, probably without even knowing it. Gmail finishes your sentences. Your phone corrects your spelling and grammar. Instagram decides what to show you next. Spotify creates perfect playlists of new music. Advertisements know exactly what you’re thinking. You use AI hundreds of times a day.

For some of us, this is an uneasy truth at first glance. We imagine computers ruling our world with cold efficiency, slowly robbing us of our freedoms. But AI is not the villain from our favorite dystopian movies. As fun as it is to get lost in the world of Terminator‘s Skynet, I,Robot‘s VIKI, or Captain Marvel‘s Supreme Intelligence, AI is far less sinister in real life. 

AI is a tool, helping to solve problems that require enormous computing power. It’s lines of code that process millions of haystacks worth of data to pull out a single needle in a matter of seconds. 

The point: AI is everywhere, and it’s not the far-off villain of Isaac Asimov horror fiction. AI is a tool that is seamlessly integrated into hundreds of your daily experiences. It’s not just for nerds anymore. 

Especially in business, there are a few things you should know about this tool if you expect to remain competitive in the coming decade.

3 Things You Need to Know:

(1) AI is Now a Commodity

Until recently, artificial intelligence was mostly the subject of science fiction writers; today it is the subject of your average software engineer. The application of AI has come a long way.

The business community has witnessed an integration of AI on a grand scale. Ubiquitous in all markets, it is written into many of the functions that we use on a daily basis. Furthermore, companies like Amazon and Google have used unimaginably large collections of data to perfect AI tools, and have commoditized them in the form of products like AWS and Google Cloud.

Some have chosen to ignore AI, not seeing value in tools they can barely understand. Meanwhile, fields that lean heavily on AI (like data analysis and business intelligence) have expanded rapidly in recent years. For example, CIO.com lists “BI Analyst” as the most in-demand tech job of 2019. AI is changing business.

A great example comes from an interview with the Harvard Business Review, MIT Sloan School professor Erik Brynjolfsson. He describes an AI program that reviewed recorded conversations of successful sales, and then listened in on active conversations between salespeople and potential customers. While they were on a sales call, the program used the data from successful pitches to make suggestions about words or phrases that the sales person could slip into their conversation to help close the sale. This small application of AI boosted sales by 50%.

Brynjolfsson strongly believes that the only thing holding businesses back is a lack of imagination by business executives on how to use these new tools in their businesses.

(2) Your Competitors Are Using AI

Even if you have a few data analysts on staff, you’re most likely not getting the most out of your software. Since AI is everywhere, it’s hard for CIO’s, tech leads, or business owners to find and use the full range of the tools that are available to them. For instance:

your CRM could be generating leads for your sales department in places they wouldn’t have thought to look

your supply chain solution could be dramatically cutting waste by ordering supplies to be delivered for the lowest shipping cost at the exact moment they are needed  

your security solution could be identifying fraud and malware threats before they strike, saving you the time and money you would have spent recovering from one employee clicking one email

your ERP could be spotting spending trends and suggesting campaigns to your marketing team 

You might ask yourself, Is it worth all the hassle? Do I really need to do all this? I’m getting along fine without AI, why would I change? If you’re asking yourself this question, you’re looking backwards, not forwards. Failing to make the most of AI is not just a missed opportunity; failing to utilize AI is an increasingly significant liability. 

The proof is in the numbers. Netflix claims that a machine learning tool saves it $1 billion a year. Amazon used AI to influence the decision-time of online shoppers and cut it by more than a third. HBR found that companies using AI for sales were able to increase their leads by more than 50%, reduce call time by 60%, and realize cost reductions of 40%. If you don’t take advantage of AI, you will lose out to someone who is.

AI is now a necessity; it’s simply integrated into everything you do. Your CRM, ERP, website, and applications are all using AI. If you aren’t making the most of it, then this low-hanging fruit is spoiling inches from your hand. That is, if it’s not being snatched up by your competition.

(3) The Catch: It’s Not Magic

AI is certainly low-hanging fruit, and it doesn’t take an enormous investment to get more out of it. But it’s not a magic solution that will fix everything. AI is a complicated tool, and getting the most out of it requires knowing how to use it. Utilizing AI takes work. And worse, if you don’t use it correctly, then AI could actually lead you in the wrong direction. Ray Dalio put it best, “Be cautious about trusting AI without deep understanding.”

AI is a tool, and just like any tool it can be used improperly. With AI, bad input means bad output. There’s an art to using this tool.

Here’s a simple illustration. At one time or another, most of us have used the online radio service, Pandora. The process is simple. Tell Pandora a song or an artist that you like, and it searches an enormous music library to play a song that is similar to your input. You rate the suggestion in order to help Pandora hone in on your taste. This is AI at work, learning from your preferences.

But a tool is only as good as its users. If you vote thumbs down on your favorite song, then Pandora won’t play it again. Or if Pandora hadn’t invested in a large and diverse enough music library, it wouldn’t be able to return songs similar to the ones you like. The tool needs to be used properly in order for you to get the most of it. 

AI solutions in business are no different: you need to use the tool properly in order for it to work properly.

So How Do I Do it Right?

There are three main components of a good AI implementation in business: know yourself, know what you need, and use the right data. If you don’t have all three of these components then at best you’re not getting the most out of AI, and at worst the tool will lead you in the wrong direction.

First: Know Yourself

An AI solution isn’t worth the investment if it doesn’t solve the specific problems facing your business. This makes sense in theory, but is hard for executive leaders to get right in practice. 

The reason for this is not hard to grasp. CIO’s or VP’s of Sales have deep knowledge of their own departments and the business verticals relevant to them, but good tech integrations require organization-wide implementation, and this always pushes beyond the knowledge of a particular individual or department. It’s hard to see beyond the boundaries of your silo.

We begin every project with a current-state assessment. This seems like a logical first step, but it’s often overlooked. It involves gathering requirements that clarify the current-state needs and processes that are affected by a solution. This gives you a clearer understanding of what you need in the future. Many executives assume they already know this, but even the best leaders have blind spots. 

A current-state assessment is the best starting point for any kind of project work, but it is especially important with AI. If you don’t have a crystal clear understanding of what you need from an AI solution, then all that will change is the speed in which you receive unusable or incorrect answers to your business problems. 

A worthwhile software integration must always begin with a careful look inward, with an up-to-date assessment of requirements gathering and process mapping. Failing to do this has its consequences. If AI is integrated into an organization’s workflow without this look at your current-state, the result is solutions that don’t fit your business or market. 

Second: Use the Correct Inputs

What sets real-life AI apart from fictional AI is one key aspect: general intelligence.  AI can solve some problems faster and better than humans, but it can’t think for itself. 

For example, AI programs have bested world champions in Chess, Go, Texas Hold’Em, and Jeopardy!. But there’s an important detail: the same AI that beat champions in chess can’t even play the game of Texas Hold’Em. Another example: an AI program has to sample tens of thousands of photos before it can identify animal pictures with any reliability, whereas a 2-year-old can correctly identify cats after only seeing one example. 

But it’s not just games and image recognition: there are darker examples of AI falling short in big ways:

Developers at MIT were excited about the accuracy of their AI facial recognition software, until they realized that they forgot to build inputs into the software that could identify darker skin tones.

Biases built into AI solutions in law enforcement yielded inaccurate results with huge consequences, such as falsely singling out minorities for recidivism or counseling police to target ethnic neighborhoods. 

Amazon used an AI recruitment tool that spent 4 years sorting out the resumes of female applicants, even specifically flagging the word “women” as cause for downgrading a resume. 

AI tools are narrow, specialized solutions: you can’t expect to solve problems without teaching it how. It takes work to shape the tool to work correctly. Well-defined and clearly-articulated problems are inseparable from successful AI integrations. The payoff comes once a computer knows how to do a task properly, and can do it at a speed and volume that humans could never achieve. The good news: this work is absolutely within your reach, and most off-the-shelf software has easy-to-use feedback loops built in to help you!

Third: Use the Right Data

Imagine searching through a deck of playing cards to find the midday market report. Or searching through a 4-pack of crayons looking for an exact match to Robin’s Egg Blue. If your data set isn’t large enough or doesn’t fit your questions, then you aren’t going to find meaningful answers. This is especially true for artificial intelligence. 

This can be daunting for someone new to AI. How do I know if data is high-quality? How do I know if I have a sufficient quantity? Without the help of experienced input, executives might be making data purchases that are unhelpful, or even harmful. The consequence of using AI with insufficient or bad data is inaccurate solutions and misdirection. 

One Last Consideration: Don’t Reinvent the Wheel

Your business is unique, but your problem is not. Why spend time and money custom-fitting an AI solution to your business when a tool has already been developed for just that problem? Finding the right solution might just be a matter of having someone who knows the market helping you find the solution that fits your business.

Using Artificial Intelligence Well: A Case Study

A client of ours was experiencing stagnation in their financial and customer growth for the first time in their history, and couldn’t identify the reason for the slowing growth. They turned to The Gunter Group to help them revamp their digital strategy in order to expand to new customers.

This client had years of data on their customers that they didn’t know how to leverage. They offered great service, but they didn’t understand their customers’ behavior. So we started there.

We began with collecting their data, which consisted of several different types that needed to be aggregated into one system. We helped them build a unified repository, so that any insights they sought maximized the value of their data. In addition to helping them improve the quality of their data, we also helped them refine the insights they hoped to gather. At the beginning of the process, we engaged our experienced Business Analysts to help them integrate their knowledge of their organization’s structure and business goals into the process. 

With the 3 important ingredients in place, we were ready to make the most of an AI integration to explore the data. Our team helped craft complex algorithms to create customer segmentation, cohort development, churn prediction, and market share analysis. They were able to use these insights to launch highly effective marketing campaigns, and began a path to predictive analytics to enable real-time interventions in the future. 

This kind of example abounds in the business community today. Artificial intelligence is quickly becoming a commodity, available to all. You can’t afford to stay behind the curve. 

The Gunter Group partners with organizations in Portland, Vancouver, Bend, Salem, Reno, and Sacramento, helping them to know themselves and seize the low-hanging fruit of AI. If you are interested in learning how we can help you to do the same, reach out today!