Post-Merger Blues: The Accidental Enterprise Architect (Part 1)

Posted by Tim R on October 17, 2018

bridge-3614035_1920

The unexpected beginnings of a dynamic career

 

Your days consist of fitting business needs with IT capacity.

Patterns in an organization appear before you like a cascade of green binary.

And, most importantly, co-workers don’t totally hate talking to you…

At some point in time, whether or not you even realized it, you became an Enterprise Architect—that rare breed of crazy that speaks IT but thinks in business.

But it wasn't a fluke.

After your company made that industry-shaking acquisition, it needed blood to flow between its fresh new limbs. All new and old assets in your organization required examining to determine if they could support the scale of this unprecedented growth spurt—and an integration strategy had to be managed by someone who knew the organizational body well enough to manage the transplant.

 

Enterprise Architecture Success Kit

 

So the buzzword “digitalization” was floated about—that very concept which you’d spent the past ten years championing. This once radical belief that IT and business data should exist in a decentralized environment to create transparency and open collaboration was now optioned as key to a successful merger.

Again you stood before your corporate teammates and shared the benefits (speed; cost; happiness) of fluid microservices over inoperable monolothic applications.

You repeated (oh-so-patiently) why a fully integrated enterprise, one in which each application is mapped to an overall business service flow, could actually be governed within standardized frameworks.

You described how a modernized IT landscape would allow the organization to change not just for the better, but actually become better at change itself.

Applause followed. It was, quite possibly, the greatest speech on IT ever made.

So good, in fact, that your boss made a quick tally of your qualities…

  1. Tech-savvy
  2. Agile mindset
  3. Evangelistic
  4. Data-driven
  5. Ability to execute

…and entrusted you with harmonizing these duelling IT and Business landscapes into a cohesive, submissive architecture.

To begin, you wisely assessed the expectations of key stakeholders. What did they want to accomplish with a new architecture? Did their hopes and dreams match reality? Was there a consistent vision to base a new architectural strategy?

And, most importantly, did they understand your role as Enterprise Architect?

Though all parties involved wanted the post-merger business to be fleet and cost-effective, it had not yet introduced the methodologies necessary to simplify operations on such a large, cross-divisional scale. Cost-cutting and trimming could not happen until teams documented their applications, and the real value of any single team’s applications could not be measured unless seen from within an organization’s total workflow.

Information had to be collected in effective ways—but also be shared and evaluated in equally collaborative manners to drive analytics.

Doing so meant your organization needed a single repository to house its data, a spot accessible from anywhere and to anyone with potential to enrich its contents with stronger details. A space where applications might be mapped according to business functions; a synergetic arena where the measurements of enterprise architecture could be clearly observed.

A “source-of-truth”, as it is known. Perhaps an honest-to-goodness modern EA management tool!

With it you estimated you’d gain enough transparency over your merging enterprise to do the following:

Reduce Costs, by

  • eliminating redundant applications
  • consolidating vendors

Reduce Risks, by

  • avoiding IT incidents by foreseeing obsolescence
  • ensuring compliance standards

Be more agile, with

  • effective knowledge sharing
  • decreased complexity through collaborative insights

The prospect made you feel good. It also made your CIO and many IT Managers feel good by assuring them you were searching for an all-in-one solution to their most pressing doubts about Enterprise Architecture. Namely:

  • How can you track the relevance of applications in a changing business?
  • Which technology does the company depend upon? Can this data be optimized?
  • Can you locate at-risk technology far in advance?
  • Where is our data—and how is it being used?
  • How are our vendors being managed?
  • How much is actually being spent on IT?

Unfortunately this was only the beginning. Now you needed real evidence to convince them how and why EA was essential for ongoing transformation efforts. And fast.

This is why your first 100 days as an EA were critical…

 

Learn about what happened next in Part 2 of our Accidental Enterprise Architect blog series. In the meantime, however, we'd love to hear your opinions on how to make it in the fast-growing field of Enterprise Architecture. Is there a well-trodden path to this career? If so, what are the essential skills?

Please share your comments below!

Subscribe to the LeanIX Blog and never miss a post again!

Related Posts