This must be my season for enterprise application architecture. To be honest, I have not even thought about application...
architecture for a long time. But in the past few weeks, I have been confronted by three separate application-architecture situations.
In the first, I was having lunch with one of my IT gurus. This guru is typically on the forefront of the next wave in IT, and so I like to get together with him every so often and pick his brain. As we were discussing the looming anytime, anywhere nature of IT, he leaned back in his chair, looked at the ceiling and asked, "Do we really even need to talk or think about enterprise application architecture anymore? It seems that we have outgrown it."
He then returned to our conversation about anytime, anywhere IT, and I kind of blew off his comments about enterprise application architecture being passé.
A week later, I got a call from one of my CIO friends. Her company recently completed a global implementation of ERP. The rationale for the project was to get the entire organization onto a common set of business rules and horizontal processes. Now it seems that departments and business units are busy creating application silos by localizing their business rules, and defeating the purpose for the ERP. After she had explained the problem, she asked for my advice. My first thought was to blurt out, "It sounds like you need to develop a solid enterprise application architecture." But, haunted by my guru's comments on application architecture, I instead offered my condolences and asked her for some time to think about her situation.
Then, to confirm that I suddenly am living in the nexus of the architecture universe, the vice president of engineering for a software company asked me to assess his company's suite of applications. It seems that the engineering team, in order to be responsive the demands of the business, has created a lot of potentially overlapping applications. For example, the company has six payment processing applications and four customer registration modules.
More about integrating enterprise applications
Best practices for a SOA implementation and application integration
Enterprise application integration and development: Special report
At this point, I decided the application architecture gods were sending me a clear message, and so I decided to think once again about enterprise application architecture.
And, after spending a few hours with the software company's development-team leads, I have reached a new set of conclusions about application architecture. These conclusions are:
- My guru was only partially correct. Application architecture is not critical if our applications are homogeneous. For example, at my company, we have been able to get all our ERP tools, as well as tools for CRM [customer relationship management] and business intelligence, from a single supplier. In effect, we purchased an application architecture when we standardized on that platform.
If the environment is heterogeneous, however, an application architecture is a great way to either design for or trend towards standardization. For the vice president of engineering, a well-thought-out, accepted architecture would avoid development teams working on the seventh payment processing application. For my CIO friend, an accepted architecture might hedge against the drive to localize the ERP business rules.
- To lay out a cohesive application architecture, think horizontally. For example, payment processing is an application that cuts horizontally across much of the organization. The foundation of a good architecture consists of applications that are horizontal in nature.
- Use building blocks of common services. As you think horizontally, identify the set of common services and interfaces that will allow you to build applications for today and the future. The best toy I ever purchased for my active, demanding sons was a huge collection of Legos. With just a few common and reusable, yet differently shaped blocks, my sons could entertain themselves for hours.
What are our common and reusable, yet different services? For my CIO friend, we identified that each business unit needed to place an order, ship an order and account for an order. The resulting application architecture defined the standard set of applications that provided these services and the set of standard interfaces for communicating among the services. With these defined, there was no need to localize the services as long as the services placed an order, shipped an order and accounted for an order.
- Treat exceptions like exceptions. Too often, our application architecture becomes heterogeneous when we attempt to automate the handling of all possible exceptions. Exceptions are called that because they occur infrequently. My architecture anticipates that we will handle exceptions manually until they become the norm.
- Complexity is the enemy of flexibility. My CIO friend was right to be worried about localization of the ERP business rules. If each business unit and department created its own ERP configuration, complexity would rule. Complexity is the bad gift that keeps on giving -- and not just the costs of supporting the overly complex ERP system and its future upgrades. In an age when time to market is essential, complexity stands in the way of IT and business agility. One goal of a good application architecture is simplicity.
- Make sure the business understands why an architecture that is horizontal, that is simple, uses common building blocks, and treats exceptions like exceptions is a great thing. There are solid business reasons for a quality application architecture, and I have never yet had anyone fight me on architecture as long as I explain why these characteristics are important to the business (and not just IT).
The vice president of engineering developed a pilot architecture that consolidated and standardized various services. The result was more development resources to work on products that created competitive advantage (a seventh payment processing application definitely did not). My CIO friend worked with her business units and departments to define an architecture that thwarted most localization attempts. And I have been avoiding my guru friend -- I don't want to tell him he is wrong about enterprise application architecture.
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at email@example.com.
The importance of enterprise application architecture strategy
Emerging trends in enterprise application approaches
Dig Deeper on Enterprise application development, DevOps and software agility
How I learned to love Agile ERP and why you should too
Smart process applications: Taking a new method to business processes
Three ERP-BPM integration mistakes to avoidBy: Chetan Manjarekar
Making sure your business software stays business-ready