Is Application Economy an ‘Architectural Moment?’
WHAT WE HAVE ON THIS PAGE
By Michael de Groot, Geneca
In today’s fast-paced world, new information is constantly available at our fingertips. People are leading increasingly digital lifestyles and, if it hasn’t happened already, you’re going to be compelled to deliver your offerings as some kind of digital product or experience. This new “application economy” is going to stretch your IT group in entirely new ways.
As an architect, not only are you involved in making decisions about your group’s technical direction, you also influence the culture of your IT organization as a whole. For better or worse, being successful in the application economy requires more than just picking the right technologies.
It is a given that “business as usual” is no more. We now need to think and act like nimble software companies in order to adapt to the changing needs of our clients.
Is your team ready for the challenge? As an architect, how can you help your team emerge a winner in the application economy?
Get to Know the CMO
One of the first things the IT group needs to do is establish a stronger partnership with its business partners. In the new application economy, your list of stakeholders has grown and now includes the CMO. The CMO is quickly becoming an integral part of the “business partner” team that provides you, IT, with your outside connection to the intended user base.
A relationship where business – in particular marketing – works in lock-step with the IT group helps to reduce time to market, enable innovation and deliver the experience required to win and retain customers.
Language of the Digital Economy
One of the easiest ways to start a partnership with the business is to stop requiring that they talk like IT does. Instead, IT should learn the language of the business.
By trying to bridge this gulf, not only does IT get a better understanding of the business and what problems it is trying to solve, it also helps ensure that both groups are on the same page regarding functionality and scope.
For example, consider estimates. Estimates are always requested by the business, yet are rarely defined in terms that the business understands. What good is an estimate if the business doesn’t fully understand the “cost” of the project? If estimates are presented in a way whereby chunks of discrete units of business functionality have an associated development “cost,” the business is then able to better prioritize what IT should work on and when. The ability to prioritize allows the business to release bits of functionality sooner instead of having a group of functionality be held hostage to the development of a feature that may be unnecessary or that takes longer to code.
IT also needs to involve the business in major decisions affecting the project. For example, if scope must change due to delays (or the scope of a functional unit suddenly expands), the decision on what to do next should involve a conversation with the business. Although IT should serve as a trusted advisor to guide the business in their decision making, IT needs to let the business make the final decision. Failure to step aside can result in the release of a product that fails to meet the business needs of your company’s clients.
User Feedback
In addition to forging a new relationship with the business, the IT team itself needs to become more flexible and responsive.
The use of continuous feedback loops can help the team adjust and manage more easily to business objectives and schedules. This may include the use of post-mortems after each delivery, regular status meetings with the business, and the breaking of business functionality into discrete, standalone building blocks. (Just as children playing with Legos understand that anything can be easily built from little discrete blocks.)
Continuous feedback from previous iterations or projects will help you apply the lessons learned to current and future development cycles, enabling faster (sometimes in parallel), more responsive and more efficient development.
Adaptable Application Design
Adaptable application design represents yet another major change that architects must adapt to in the application economy.
It’s almost a given in today’s world that end users are able to “do things for themselves.” No longer can architects and developers continue to think of applications as standalone silos. Architects need to adapt and thus design applications where the back-end logic can service multiple user interfaces that may have very different requirements.
Borrowing again from the Legos metaphor, this may mean that business functionality needs to be decomposed into discrete units that can be combined by the applications that consume them. Because of their usefulness in solving these kinds of problems, concepts like service oriented architecture (SOA) and enterprise service busses (ESBs), originally utilized by very large enterprises, are now making their way into the mainstream. It is important that architects familiarize themselves with these concepts and technologies, and adhere to solid architectural principles like the separation of concerns and the following of well-established patterns.
Remember, having multiple user interfaces will pose additional challenges when it comes to profiling the performance and scalability of your system. Many of the multiple user interfaces consuming your application may have wildly varying non-functional requirements. Simply having the system “seem responsive” in a development environment for a single-user scenario will no longer be sufficient to guarantee that your system correctly responds to the demands of the future.
As a result, performance and horizontal scalability should be considered early on in the design phase of every project rather than just being reserved for “large” projects. In addition, architects should become familiar with and rely upon profiling tools so they know how their application will perform when it is “in the wild.”
Every Company Is a Software Company
Whether your company’s core business is insurance, advertising or the sale of widgets, in today’s application economy every organization needs to think and act more like a “software company.” As IT leaders, architects are in a great position to not only recommend the technologies that enable more digital offerings but to lead and create a team culture that encourages innovation and growth.
Creating partnerships with the business, becoming more flexible via the use of feedback loops and architecting your applications to maximize horizontal product growth will ensure that you keep up in today’s fast-paced application economy.
As Geneca’s Chief Architect, Michael de Groot excels in matching technologies to business needs. A customer-focused, 20-year software veteran, Michael has a broad knowledge of architectural, software, enterprise, Web-based and mobile design patterns. Independent of the platform, Michael provides tactical and strategic technical leadership for Geneca’s enterprise application projects.
Paul Ferrill has been writing for over 15 years about computers and network technology. He holds a BS in Electrical Engineering as well as a MS in Electrical Engineering. He is a regular contributor to the computer trade press. He has a specialization in complex data analysis and storage. He has written hundreds of articles and two books for various outlets over the years. His articles have appeared in Enterprise Apps Today and InfoWorld, Network World, PC Magazine, Forbes, and many other publications.