Enterprise Architecture As The Blueprint For Your IT’s Future

“Why should one need an enterprise architecture ?” Inno.com’s Johan Van Looy started the masterclass on EA with a legitimate question. The answer is quite straightforward, he believes: “Enterprise architectures allow you to secure added value for your investments today and in the future.”

Do we need a standard CRM system or do we need to customize? What’s impact of that decision on the business strategy? What’s the impact if we decide not to follow that strategy? The answer to those questions can seem to be common sense. Therefore, do we really need to create more administration and an EA?

“Quite honestly, if you solely use standalone cloud applications for standard processes: no, you don’t. But. First of all, you cannot ship everything to the cloud and there’s no all-in-one solution – even if IT is commoditizing. Most IT models are hybrid today, with a combination of on premise and cloud. Moreover, companies make a difference through their own business processes. Those require specific application development or integration with other tools. If you want to keep track, you best invest in an architecture.”

An enterprise architecture is like a blueprint for your application foundation and its alignment with the business. But it is also a business plan to measure impact of certain decisions or change. Plus, it helps to communicate to the Board where IT is headed. It allows board members to have minimum knowledge about IT and the IT strategy. As such, an enterprise architecture is also a tool to start a strategic dialogue about information technology within the organization. Additionally, it is useful for your n-1 to take decisions independently.

Two alignment tools

Unfortunately, there’s no greenfield scenario to draw an EA sketch, as you always have a legacy you need to align with. There are two tools for this alignment: the blueprint scenario, which is both a high-level analysis for management as low-level interpretation of your existing applications, and the technical debt scenario, which is a metaphor to measure the impact of your application heritage on current architectural decisions.

1) IT Blueprint – looking at the future

The blueprint is a hypothesis of how your application architecture should look like in the future. It is the result of a brainstorm with the business and serves as an instrument to steer application investments en make them converge with your strategy. It is therefore not the business’ wish list, but a tool to create a transverse structure that servers the different applications of your divisions.

We see that enterprise architectures often become roadmaps when outtasked to operational IT management.

How to create such an hypothetical instrument? You need to group business and IT drivers. Compare it with a forest and its different trees. All trees need a different treatment, care. You need to cluster them. Same goes for application architectures. You first make an functional cluster, per business process. What applications have functional cohesion but also have the same technical requirements?

You can use Gartner’s pace-layering model for this, to make the list of your commodity applications, your differentiating applications and your innovative applications. Once you have the clusters, you try to define a strategy for it.

“At bpost, for instance, we decided that CRM was not differentiating. That means that the CRM applications in use had to be replaced by standard applications. Every customization request was countered with the question how it would be differentiating for bpost. It allowed us to stick to the standard cluster most of the times. If a smart businessman happened to find a differentiating process in CRM for his division, that was fine. We simply changed the blueprint. That’s what the hypothesis is about. It is not a roadmap nor a target, but the result of discussions with the business.”

“The blueprint approach is highly valuable as it is not the standard definition of the target and fixed wish list of the business”
Peter Bal, CIO of Wabco

We defined 7 clusters at bpost. In a second phase, we looked at all applications inside the clusters. Which functionality is important for the heart of the organization? Which application are we to keep and which one should we decommission? Combine a top-down and bottom-up view on your applications, to keep in touch with the operational business and reality. “If you for instance have an application that you wanted to decommission but you have invested quite a lot in it, what should you do? Keep it or invest a tiny bit more to decommission it and replace it by a new system that adds more value? That’s how you work with a blueprint. Make a landscape that fits for purpose.”

What to do when you have to divert from the cluster’s hypothesis? No problem. Sometimes you need application that can ignore red lights and drive faster like ambulances. If you have too many exceptions, you’ll have to reconsider the blueprint. Or analyse why you need to divert, and go back to the business with that feedback. Again, you’ll never reach the blueprint as such. You can have target architectures though. In five years’ time, we should have reached X or Y. A ‘foreseeable future’ is an intermediate step on your way to the blueprint, which is much more volatile.

2)Technical Debt – considering the past

The past may weigh on your architectural investments. Logically you make investments for your application projects. If your system doesn’t change, no problem. But there are hidden costs like documentation of code, training new software engineers. As it grows bigger, the TCO of your application grows equally ánd exponentially. The smallest change to your application will be at costs that seem out of proportion for the business because of lack of documentation, spaghetti code, etc.

Bad news: you will always have this technical debt. You have to avoid that code turns into spaghetti, but you cannot and should not document everything. It is a trade-off. Should we quickly add a few lines of unoptimized code as the software is to be decommissioned anyhow, and the positive interest of the change is higher than that debt? Is your software architect a fixer that helps the customer but doesn’t care about the debt or does he want everything to be picture-perfect?

In this model you always measure the interest versus the technical debt of architectural changes. Automotive companies create conceptual cars that will be commercialized later on. Those concepts are their debt. It proves one absolutely needs a blueprint to encompass the future. You need to gather project leaders twice a year to renegotiate the blueprint and avoid that you are creating a bigger technical debt that you could have avoided. You architecture is as good or as bad as your ability to do this.


DE PERSGROEP STREAMLINED IT WITH AN ENTERPRISE ARCHITECTURE

In 2012, after a 3-year investment freeze, publishing House De Persgroep was facing a functional backlog. The application portfolio needed revamping and large investments were realized in 2014-2015, also because its IT staff needed to integrate the two large competitors the publishing house had bought. Additionally, print and digital staff were integrated and every company of the group had to follow that same business model. It had a big impact on the application portfolio.

De Persgroep decided to get an Enterprise Architect on board to steer the investments needed. “IT was very fragmented in the past. It used to be very different in distribution, content or circulation”, says Isabel Van Mele, Enterprise Architect at De Persgroep. “We needed to centralize our IT systems in order to integrate acquisitions more easily but above all to cope with the trend towards digitalization and the ‘fight’ for the online reader. Big data and digital is where we make money: targeted advertising, hybrid subscriptions, etcetera. Data is crucial for us and therefore our architectural landscape is changing. Slow batch systems won’t allow for quick analytics. Hence the need for a structured and future-proof enterprise architecture”

Functional building blocks

Van Mele first broke down the silos. Through discussions with the business, she was able to see which functional building blocks where needed across the organization to build upon, like right-time bidding, digital, big data and online advertising. These insights into functional processes allowed her to create a referential framework that the business understands. On a technical level, she drew a map with hundreds of applications in a ‘targeted architecture’.

“For each building block, we created logical layers”, Van Mele explains. “This way, you get insights into duplicate functions or applications that support a functional building block, like circulation management, across all companies of the group. This approach gave us an overview of monolithic applications that you want to decommission, allowing better integration and big data/ analytics.”

When talking to the business, Van Mele uses checklists and standard questions that cover the functional but also non-functional concerns, such as performance, security or availability. The result is then held against the data model. “When we acquired Wegener, we held their software against this targeted architecture to see what IP to take over and integrate. It appeared we would need to reduce the application portfolio from 350 to 150. IT was able to predict the integration period ánd gave tools for negotiation, as the exercise amounted to 13,5 million euros. Such an exercise can only be done as fast if you have an enterprise architecture.”

Three architectures

Today, De Persgroep has regular review meetings with the three architectures and their respective architects: business architects (that define the functional side), technical architects (that make sure that we can integrate and design the applications) and infrastructure architects. The infrastructure architects are now integrated much faster in the process than before. It therefore defined a set of so-called ‘principles’, that clearly indicate the impact of possible changes to the business.

“Enterprise architecture gives you different views to look at your organisation. Thanks to the helicopter view, you get to see reusable services. At De Persgroep, enterprise architecture allowed us to drive the necessary to prepare for future but also current challenges. You want to evolve to an architecture that brings business agility and do the right things right. This model also creates trust with the business. They now ask us to audit cloud software and integrate it in our application model, instead of commissioning it themselves. We avoid shadow IT and gave a negative audit, for cybersecurity reasons”, Van Mele concludes.


CASE BEKAERT: ENTERPRISE ARCHITECTURE TO FUTURE-PROOF IT

Steel thread manufacturer Bekaert has become a conglomerate of numerous little companies across the world. IT is a global service: technology and applications are centralized in global data centers, but the delivery is a local assignment. “We immediately convert acquired companies to our application portfolio”, says CIO Bart Vandecappelle. “We standardize technology as much as we can.”

The application and global IT portfolio has become much larger over the years with SAP as the biggest chunk but also SuccessFactors, Microsoft SharePoint, Office 365, the wide area network, the two data centres of the group and so on. “Our old ‘easy-to-manage’ application architecture has become more complex and a lot of the new building blocks need integration or antennae in the cloud, etcetera. Above all, the business wants speed of change, agility in switching solutions. Hence the need for an Enterprise Architecture.”

The CIO’s challenge is two-fold. First, make a business case for the new function ‘as the IT ain’t broke now’. Secondly, Bekaert is strong outsourcer: application development to TCS and infrastructure management to HCL. That would seem to reduce the scope or freedom for the enterprise architect.

Data management will probably be the first functional block to formalize. “Our focus today is still on running operational systems. If we want to go for digitalization, we’ll need to change our approach. Also with regard to enterprise architecture”, says Bart Vandecappelle.

Download white paper