By Leonard Greski, Practice Lead, Architecture
It was the end of a tough day, and Rory, VP of Enterprise Architecture at a Fortune 500 company, needed a stiff drink[1]. Late July is hot and muggy in Miami, and on this day the angry executives were as oppressive as the weather. As he pulled out of the company headquarters parking lot, Rory found the luxurious accoutrements of his BMW X5 an insufficient distraction from the predicament in which he found himself.
He had just spent 8 hours in a brutal quarterly operating review for his business unit, where Mitch, the business unit president, eviscerated the IT department for its eight-year failure to deliver a mobile commerce platform, which had been languishing as a skunkworks project within the IT Innovation team. Growth of the e-commerce business had been declining for years, leading the company to hire new business and application development leaders earlier in the year to revitalize it. The new leaders were seven months into a multi-year e-commerce transformation effort, and as badly as they wanted to build a mobile platform, mobile commerce had been explicitly excluded from the transformation scope.
Tired of Grady, the VP of Innovation’s excuses for why his innovation team failed to deliver anything of value for mobile commerce the last eight years, he scanned the room looking for someone, anyone, that he could trust to produce tangible results quickly. Mitch tuned to Rory and issued an ultimatum, “We have our annual meeting with industry stock analysts on November 16th. We are going to demo a new mobile commerce platform at this meeting, or else!”
Adding fuel to the fire, Peter, the newly arrived SVP of e-commerce, chimed in, “I delivered mobile commerce at my last company in only 6 months, and we were #9 on the Internet Retailer 500. I outsourced the work to a mobile commerce specialist, and they even delivered a custom search engine for us.” Not wanting to be outmaneuvered by the new guy, Rory publicly committed to delivering a mobile e-commerce platform by November.
The only problem was, how?
Rory was in a bind. On one hand, as VP of Enterprise Architecture, he had responsibility to guide the intentional architecture of the organization, ensuring stability of corporate IT assets while minimizing total cost of ownership. On the other hand, he accepted an assignment that was apparently so difficult that the Innovation team couldn’t deliver anything of value in eight years. He was going to have to be agile and break some rules to deliver something that would be even remotely acceptable to Mitch. The thought of breaking his own rules created a degree of cognitive dissonance in Rory.
Complicating matters was the fact that Rory needed to obtain Peter’s buy in to a potential solution, since after all, Peter would be responsible for marketing and operating the solution once delivered to customers. As he settled into the drive home, Rory considered Peter’s idea of outsourcing the work to a boutique mobile commerce solutions provider. This approach sounded attractive because it would secure Peter’s buy in and support, but unfortunately it came at an unacceptable cost. The company’s desktop website was recognized by the industry as having a superior search experience, and outsourcing would create a risk of introducing a radically different and obviously inferior search experience on mobile devices.
Outsourcing would potentially solve one other problem facing Rory, the lack of e-commerce product development team members to work on this effort. The e-commerce team, 100+ employees and contractors strong, was fully devoted to the e-commerce transformation effort. They left behind a skeleton crew to maintain the legacy e-commerce site, but it was unrealistic to expect the maintenance team to continue to maintain the legacy site AND deliver a new mobile commerce platform.
Arriving at his garage, Rory decided to leave this rats nest in the garage for the evening, and instead focus on his wife, children, and a tall Jameson Irish Lemonade.
No Solutions in the BizBOK…
Angry executives. Changing markets. Unrealistic, and often conflicting demands. External (and internal) competitors. These are the realities that leaders face as they try to deliver products and services that win in the market. Unfortunately, we can’t solve these types of non-linear combinations of business, technical, and people challenges following a framework or methodology by rote, whether it’s BizBOK, TOGAF, BTABoK, LeSS, or SAFe.
The presence of multiple frameworks in a large organization often makes things worse, as devotees of one methodology compete with the advocates for other frameworks. While the theoretical debates rage, progress on meeting customers’ needs grinds to a halt. Situations like this require the kind of leadership fortitude and creativity that Roger Martin describes in his book, The Opposable Mind, where he cites the American author F. Scott Fitzgerald:
“Sixty years ago, F. Scott Fitzgerald saw ‘the ability to hold two opposing ideas in mind at the same time and still retain the ability to function’ as the sign of ‘a first-rate intelligence.’”[2]
Detangling the Rats Nest
After a nice Irish cocktail, dinner and a good night’s sleep, our hero Rory prepared to attack the rats nest with vigor. He sent an early morning SMS to his erstwhile assistant, Betty, to clear his morning calendar and give him time to formulate a plan. After arriving at the office, he decided to organize his thinking as a force field analysis. That is, what forces are driving (supporting) delivery of a mobile commerce offer, and what are the forces that are restraining it? As he added post it notes to the whiteboard in his office, an interesting pattern emerged.
The mobile commerce effort was essentially “stuck” in an innovation team because the lack of a business case meant that Sales & Marketing wouldn’t commit to incremental sales goals to cover the build and operate cost. Therefore, the organization couldn’t justify funding the investment.
Rory then began to brainstorm how to mitigate the restraining forces.
If he could enlist Peter, the e-commerce SVP, to build a benefits case and help him gain buy in from Sales & Marketing, he would be able to justify hiring experienced mobile e-commerce contractors to do most of the work. He would also need Peter’s team to confirm customers’ most urgent needs in a mobile solution to aggressively define a minimal viable product and prevent scope creep.
If he could prevent this work from competing with the desktop e-commerce platform replacement, maybe he could convince Charlie, the e-commerce application development VP, to lend some of his maintenance team to serve as subject matter experts, guide the implementation, and keep the contractors out of trouble. If he could frequently demonstrate regular progress towards a working tested product he could leverage Mitch’s support and prevent Grady from sabotaging the effort.
Getting Peter to agree to use existing assets rather than the vendor partner from his last gig was going to be a challenge, but Rory didn’t need to solve that problem today.
Having established workable short-term solutions for his stakeholder management risks, he pivoted to how to get the work done. This was going to be an extremely high visibility, high risk product development effort. Rory needed a leader he could trust to not only avoid getting eaten by the sharks, but also to deliver a product that customers would love to use without creating a mountain of technical debt.
Who did he know with e-commerce delivery experience that he could ask to lead this effort, someone who wasn’t already working on the desktop website transformation?
Barbarians at the Gate
Rory was clearly living the luck of the Irish because, ironically, the answer to his question sat in a cubicle three feet away from his office door.
Loretta, Director of e-commerce Architecture, had previously led the company’s online services business, growing it from $160 million in revenue to $225 in million over a two-year period. However, after losing an argument with the prior e-commerce VP about whether to fashion the online shopping experience after the children’s virtualpet website webkinz.com (yes, sometimes reality is so crazy that you can’t make it up), Loretta was suddenly deemed “too valuable to the company as a solution architect” and exiled to the Enterprise Architecture department. Little did Rory realize when he allowed Loretta to join his department how valuable she would be in his time of need.
Rory popped his head outside his office door, invited Loretta into his office and briefed her on the project. They agreed on a high-level plan to get to November, structured around completing work in descending order of risk. Loretta convinced Rory to take an agile approach to product delivery, structuring the work in two-week sprints once the architecture was defined and vendors selected.
The linchpin of the plan was to use part of August to decide whether to include Peter’s mobile commerce provider in the solution. Rory had a strong bias against the mobile commerce provider because he personally negotiated the contract with the existing search engine provider, including its mobile toolkit. Failure to leverage the existing assets would make Rory look bad in front of the other IT executives, especially Grady. He knew that Peter was going to aggressively lobby to work with his preferred vendor, but he trusted Loretta to not allow Peter to steamroll her into a bad decision.
The plan looked like this:
A key element of the plan was to be “feature complete” by mid-October, leaving about four weeks between the targeted feature complete date and the stock analyst meeting. Not only did this give the team space to test and optimize system performance, but it also provided a schedule buffer in case work did not proceed as planned.
Risk Management as the Integrative Solution
At this point in our story, Loretta has what looks like an impossible schedule on her hands. A month to conduct research, confirm scope, negotiate contracts, and install infrastructure; six weeks to build the product and a month of system tuning. Organizing the work in descending order of risk, however, gives Loretta a fighting chance because it allows her to appeal to objective criteria to align stakeholders’ competing positions around common interests.
In essence, Loretta structured her approach around the primary purpose of enterprise architecture, which is:
To be the objective guide to decision-making about business and technology capabilities.
A key reason why many architecture departments fail to deliver significant value is that they do not develop the ability to influence parts of the organization that are outside their positional authority. When an architecture department is too committed to a framework, methodology, set of standards, or technologies, it loses the ability to be perceived as unbiased. Bias chokes off influence, which marginalizes architecture during key decision-making processes. Objectivity establishes credibility, which enhances influence.
Going back to our story, Loretta not only had to manage Rory’s expectations, but she also needed to earn credibility with Peter and his chief lieutenant, Greg. The good news for Rory was that Loretta understood this phenomenon. Her first order of business became working with Peter and Greg to meet with their preferred vendor, understand the vendor’s value proposition, and figure out how to resolve the impending conflict between Rory and Peter over tooling and vendor selection.
Loretta worked with Greg, scheduling multiple meetings with the company we’ll call SyncShop. Their value proposition was to help companies quickly establish a mobile presence with a mobile-first, omnichannel approach. The more Loretta learned about the offer, the more uncomfortable she became. A key part of SyncShop’s offering was its custom “mobile first” search engine that plugged into SyncShop’s front end tools to radically reduce the amount of time it took to deliver a mobile commerce site to production. After some amount of back and forth with the vendor, it became clear that SyncShop would not agree to a contract where they had to use a third-party search engine.
The other part of SyncShop’s “secret sauce” was a toolkit they built to re-implement customers’ checkout processes via a proprietary screen scraper. Depending on the complexity of a company’s business model, e-commerce checkout processes can be very complex. Loretta learned from her e-commerce subject matter experts that it would take about 4,000 hours of labor to re-implement the current checkout process so it could be consumed in the mobile toolkit previously purchased from the company’s search engine provider. She did not have enough calendar time to deliver 4,000 hours of labor recoding the checkout process. By mid-August it appeared there was no way to escape the conclusion that if the application was going to be in production for the stock analysts meeting, Loretta had to give up on Rory’s search engine.
Rory would not be happy, to say the least.
The Opposable Mind Breakthrough
Tastes great. Less filling. Industry leading search experience. Not in production for the analysts meeting. Weak but functional search experience. In production for the analysts meeting. As Loretta wrestled with how to break the news to Rory, the tension of the opposing ideas led her to a breakthrough.
Rather than an “either / or” solution as the vendor debate had been positioned for weeks, what if we used SyncShop’s technology to screen scrape the checkout process, and combined it with our current search engine and the search engine providers mobile toolkit? Loretta acknowledged that the screen scraper approach would run slower than a rewrite of checkout, but compared to a complete SyncShop solution there would be no difference in runtime performance.
She called Greg to run a “dumb gal from the Midwest” question by him. “Greg, this may sound stupid, but would Peter agree to a solution where we used SyncShop’s screen scraper in combination with our search engine and mobile toolkit?” Greg pondered the question for a few moments, and responded, “Why not? We actually prefer our search engine, but in working with SyncShop there’s no way they’d commit to our timelines if they had to integrate it into their solution.”
Peter loved the idea. He told Loretta, “I’ve been nervous for weeks that you were gathering information from SyncShop solely to justify why we had to use our desktop search engine and mobile toolkit. I’ve been desperate to add a mobile platform to our offering since I joined the company, and SyncShop seemed like the only way to get it done this year. What you’re proposing is not only brilliant, but it also shows that you are truly listening to your business partners.”
Rory was pleasantly shocked. “I can’t believe you figured out a way not only to leverage our existing architecture, but also to eliminate 4,000 hours of labor to rewrite checkout in the mobile toolkit.”
SyncShop, realizing that some business was better than no business, agreed to a custom agreement to license their screen scraper technology. A beneficial side effect of this decision is that it resolved a significant labor risk for the project. SyncShop was a small company, and Loretta wasn’t confident that they had sufficient staffing available to deliver what they were selling. SyncShop needed fewer people to staff a screen-scraper API solution than a full end-to-end shopping experience. The company’s existing search engine provider had plenty of consultants skilled in their mobile toolkit available, so Loretta could leverage them to staff the front-end work. Additionally, use of the existing search engine cut hundreds if not thousands of hours of labor from the project to implement, configure and tune the SyncShop search engine.
Thanks to heroic efforts by the two companies’ legal teams, Rory and Loretta had necessary contracts signed with SyncShop, and the delivery team was fully staffed to start implementation by September 1st.
Integrate, Don’t Balance
A significant source of conflict between enterprise architecture departments and agile product development teams is the diametrically opposed ideas of intentional architecture and emergent design. In the Scaled Agile Framework, intentional architecture is defined as a set of purposeful, planned architectural strategies and initiatives. Emergent design is described as the technical basis for a fully evolutionary and incremental implementation approach, where the solution architecture “emerges” as agile teams build out a solution, feature by feature[3].
The SAFe website (and others in this space) assert that a balance between intentional architecture and emergent design is required. Balance as a metaphor sets the two ideas in opposition, fueling conflicts between architecture teams and agile product development teams.
A superior approach is to use the tension of conflicting requirements to spur integrative thinking. Based on a prioritized list of objective requirements, how do we reconcile the apparent contradictions? How might we use it to demonstrate our ability to collaborate, developing a level of trust that enables creativity and ingenuity?
The Rest of the Story
Loretta and Greg worked effectively as a team to manage business and technical risks. Greg aggressively established a minimum viable product of only 5 features. No need for registration, you can do that on the desktop website. No replication of marketing content beyond the basic search -> shop -> add to cart because this is easier to consume on the desktop site. Email order approval is the killer feature, and we’ve identified 5 customers who want it yesterday. In agile terms, much of the legacy website was YAGNI, “you aren’t gonna need it.”
Even with only five features, it was still an extremely aggressive schedule. Loretta led the delivery team through a series of five two-week sprints, and as an emergent design element the team figured out the best way to integrate the screen scraper with the mobile UI toolkit during the first sprint. Thus, emergent design was used to validate the intentional architecture as early as possible so the team had the maximum amount of time remaining if the screen scraper didn’t work as planned.
Sprint demos were key accountability checkpoints. The first demo included a correctly branded mobile search experience after only 2 weeks of work, and confirmation that we could access screen scraper content from the mobile toolkit. The second demo included user authentication and a working shopping cart. By the end of September the team was confident they would deliver production quality software before the November analysts meeting. Greg continued to protect the team from scope expansion. The demonstrated rate of progress, clearly visible through frequent delivery of working tested product, kept the sharks at bay.
The last feature sprint was the toughest. Checkout was complex, and the team needed more time to be fully feature complete. Since they planned two sprints of slack at the end of the schedule, they could complete the work without delaying our production launch. The application was feature complete before the end of October, and with more than three weeks to fully stress test and tune the system, Loretta’s team delivered its first production release on November 12th, the weekend before the stock analysts meeting.
The initial customers who used the system on Monday and Tuesday were effusive in their praise for the email order approval feature, giving Peter’s Marketing team great testimonials to share with the analysts. The stock analysts demo went off without a hitch. Mitch’s anger and bravado in July spurred the organization beyond its complacency. Rory was a hero, having pulled off a feat that seemed impossible during the heat of July.
The successful product launch justified the creation of a new department to manage mobile commerce, along with permanent funding. Peter and Charlie were now Rory’s allies within the senior executive ranks. The mobile commerce site not only gave Peter a new channel of growth to pursue in the upcoming year, but it also gifted a fully funded mobile commerce team to Charlie.
The business unit benefitted as well, because sales through mobile devices grew rapidly enough to earn the application a top 80 ranking on the Mobile Retailer 400 within 12 months of launch.
Key Takeaways for Architecture Leaders
I decided to write this article in the form of a business fable because, quite frankly, most content about risk management is as dull and boring as a Carnegie Mellon University Software Engineering Institute Technical Note, where the jargon is so obtuse that it’s hard to find the valuable information, let alone figure out how it applies to one’s specific situation. In contrast, the risks and their mitigations become visible through the fable as they are actually experienced in business life.
Enterprise architecture is largely an exercise in risk management. Unless architecture organizations are willing to take on risk, they are unlikely to be perceived as influential partners in solving problems. Rory established his team as a solver of gnarly problems, not complaining bystanders, by accepting accountability to deliver the mobile commerce platform.
One of the biggest categories of risk that architecture leaders must manage is relational risk, i.e. navigating the executive sociology. It wasn’t easy, but between Rory and Loretta the architecture department was able to achieve a key accomplishment, increasing the value of the company’s search and mobile toolkit assets, by establishing empathy with powerful business partners and creating a win / win solution to an urgent business problem.
Architects can use what I call “organizational jujitsu” to gain support from agile teams by positioning high quality architecture assets as accelerators of agility. That is, if the architecture department can make the use of existing assets and contracts the fastest route to working tested product frequently delivered to customers, it can leverage the Agile Manifesto values of interactions, working product, collaboration and responding to change to create support for the enterprise architecture.
For example, in this story, the architecture department provided an outstanding quality mobile toolkit and search engine that was up and running in a couple of days, usable as working tested product. The delivery team didn’t have to negotiate a new contract with the search engine provider, saving weeks if not months of schedule time. It’s a lot easier for an agile team to be agile if they’re not burning time negotiating contracts with vendors to use new components or haggling with Legal over the business and security risks associated with new open-source components.
Knowing what rules to break, and when, is also a key to effective influence. Architecture leaders must have the courage to make tradeoffs between business, technical, and people constraints, recognizing that “perfect is the enemy of good enough.”[4] In our story, “perfect” demanded a rewrite of the checkout process that couldn’t be delivered on time, while “good enough” meant delivering a somewhat slower checkout on time for a November product launch.
Finally, by positioning architecture and enterprise assets as an accelerator of agility through standard solutions that enable frequent delivery of working tested product to customers, architects and architecture teams are invited to help agile teams accelerate the flow of value because they are shouldering and mitigating risk, not avoiding or theorizing about it.
Len has over 30 years of experience helping large organizations generate billions of dollars in economic value by building and operating differentiating business capabilities. He currently leads the Architecture practice at LeadingAgile, the leader in helping
companies grow in value through business agility. He leads engagements with large clients to help them improve flow by restructuring value delivery around their business capabilities and quantifying the value of agile transformation. Len received Bachelor and Master of Arts degrees in Sociology from the University of Illinois at Chicago with concentrations in Organization Theory, Research Methods and Statistics. He can be reached at leonard.greski@leadingagile.com.
[1] This fable is loosely based on a true story, but the names, conversations and some of the circumstances have been changed to protect the guilty, as well as the innocent.
[2] The Opposable Mind: Winning Through Integrative Thinking, Roger Martin 2007, Kindle Edition p. 6.
[3] Scaled Agile Framework 6.0, Agile Architecture page.
[4] Meg Whitman, quoted in 10 Years Ago, eBay Changed the World, USA Today, March 21, 2005.