Application Architecture and Pace Layers

Discussion for EA874 Topic 2 > Application Architecture Layer

Post # 3

Applications architecture is the discipline of ensuring that application systems used to create the composite set of technology solutions for the organization is scalable, reliable, available, and manageable. It is important to understand and manage the system functionalities, data characteristics, performance and quality requirements of these solutions, and how these applications do and can work together. Moreover, it is equally important to know deployment strategies which are timely and cost-effective, managed for risks that could impact the operations of the organization, and counter to business goals and mission.

The enterprise Applications Architecture strategy for acquisition, development, and integration should always align with the enterprise business strategy of the organization. The architecture should also allow provisions for varying life cycles of different types or categories of applications i.e. recognizing those applications which are based on stable technologies at one end, and those which are volatile and at the "bleeding" edge of innovations on the other. Therefore, the organization demands a mix of applications that are both capable of robust long-term service, as well as applications that need the agility to be responsive to current market demands, in order for the enterprise to remain competitively sharp.

I was reading Altman's 2012 Gartner article on "retiring the concept of the three-tier application" in which the author speaks of technology changes and how the nexus of forces continue to impact our demands on applications and therefore the way life cycles for these applications are affected.  As he observes, there is probably at no other time have we had to manage change in so many different domains: cloud, big data, mobility, social apps, virtualization, etc. To confirm this assertion, we do only have to consider the client side of a modern application, as he points out. The broad range of UIs that applications must support continues to add to the burden of managing application architecture i.e. applications running on an array of different "client" devices, including PCs, netbooks, tablets, smartphones,  kiosks, car dashboards, GPS devices and media players. I remember going crazy with numerous test cycles that we had to endure to implement a web application on different browsers, some of which have come and gone just like a fad. The same goes for the backend with modern applications needing to support multiple data sources, possibly residing in different database platforms (not all relational) with different semantic layers, different data storage formats, and data access mechanisms.

The thing that keenly caught my interest was the notion of "pace layers" which Gartner introduced to the technology context in 2012.  It does make sense and can possibly provide a helpful way of thinking about applications. Gartner defines pace-layering as "A new methodology for categorizing applications and developing a differentiated management and governance process that reflects how they are used and their rate of change." In simple terms, this means that application systems or application components have different lifecycles, some last longer than others, and some need to be replaced more frequently. Understanding in which "pace-layer" your company's application components lie can enable more effective management of the application portfolio. The payoff, as Altman argues, is shown by the resulting IT-based solutions which are flexible, deliverable in a timely manner, and can be tailored to short-term business needs.

To my mind any concept such as pace layers can help application architects recognize varying lifecycles and timing which can better reduce architecture complexity, perhaps simplify assessments that enables better identification of robust options, and help reduce disruptive technology shifts and/or expansions.

The original concept of pace layers came from Stewart Brand, a Stanford-educated environmentalist who also views environmental elements residing on different layers evolving at different paces. Check out his blog to gain deeper insights into pace-layering. There was an even earlier concept of "Shearing layers" coined by architect Frank Duffy, which was later elaborated by Brand in his book, How Buildings Learn: What Happens After They’re Built (1994), referring to buildings as composed of several layers of change.

























Source: http://blog.longnow.org/02015/01/27/stewart-brand-pace-layers-thinking-at-the-interval/

References:

Altman, R.  (2012 September 18). It's Time to Retire the Concept of the Three-Tier Application. Gartner paper, ID: G00232626

Bridgwater, A. (2012 February 17).  Pace-Layered Application Strategies, Fact or Fiction?  Retrieved from http://www.drdobbs.com/architecture-and-design/pace-layered-application-strategies-fact/232601066

Gartner.  (2012 February 14). Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation. News Article. Retrieved from http://www.gartner.com/newsroom/id/1923014

Application Integration Blues

Discussion for EA874 Topic 2 > Application Architecture Layer
Post # 2

Application Architects should always place integration as one of the key criteria in the development and/or acquisition of application systems and components. Enterprise Application Integration is the combination of processes, software, standards, and hardware resulting in the seamless integration of two or more enterprise systems allowing these to operate seemingly as one.

I would suspect that a good portion of IT headaches -- as well as frustration of end-users, come from application systems not talking to each other, where system boundaries are far from seamless, and sharing data is primitively painful. Talk to any healthcare professional and they will lament with stories about redundant data entry because of disparate applications. This brings hours of costly inefficient overhead, demoralized personnel, diminished data quality, and poor customer satisfaction.

Ten years ago I was working for a software company which provides process automation tools to help move data from one application system to another, and thus promote systems integration.  Its HQ is in the Netherlands, and has a strong presence in Europe and North America in which two-thirds of its customer base resides. The company's core product was evolved and later co-developed with SAP in Waldorf, Germany, and is now a core component of the SAP ERP system.  We consulted for companies such as Shell Petroleum, UBS Bank, Toyota, Raytheon, and Lilly Pharmaceuticals, among many of its global customers. Further back in the 1990's I worked with IBM within the Systems Integration group, working with IBM products along with many third-party vendors to bring combined solutions for clients. Apparently, systems integration is good business for the large integrators such as IBM, Andersen, CSC, etc.

Application integration is an expensive operation, and is a key architectural concern.  Many IT organizations strategize to be agile, poised to be on the lookout for more cost-effective solutions.  Market analysts now predict that the global systems integration costs for IT organizations will be north of $300 billion towards 2020 and onwards, coming from somewhere in the vicinity of $50 billion around year 2000.

In such a scenario, it is not surprising to find IT organizations looking towards integration via automation solutions, leading to the growth of the Enterprise Application Integration (EAI) market which promises to answer that demand.  Today, the market is alive and well and could actually appear to be a confusing jungle with a cacophony of vendors for integration products. Capterra provides a current listing of integration product vendors and is referenced below.

References:

Top Integration Software Products. Retrieved 2016 Sep 9 from http://www.capterra.com/integration-software/

Radiant Insights. (2016 March 14). System Integration Market Is Expected To Reach $393.10 Billion By 2020. News Article. Retrieved from https://globenewswire.com/news-release/2016/03/14/819305/0/en/System-Integration-Market-Is-Expected-To-Reach-393-10-Billion-By-2020-Radiant-Insights-Inc.html

ERP Implementations - Vanilla vs. Customizations

Discussion for EA874 Topic 2 > Application Architecture Layer
Post # 1

I was browsing over SAP news updates on Application deployments and implementations, and can still find good coverage on the eternal debate on strategies regarding ERP implementations -- specifically on Customized vs. Vanilla implementation decisions.  I think this topic's debates and deliberations persist because it is indeed significant, with serious timeframe and cost consequences when implementing the various applications in the ERP suite. However, in my opinion, there is no one answer and correct position to this debate, and the actionable position is highly contextual on the industry, as well as the specific organization, its culture, and maturity of capabilities.

I've seen many occasions where organizations which have customized their mission-critical ERP systems over the years, will find future upgrades as extremely costly affairs and a challenging prospect. They can truly be a CIO's nightmare, and would perhaps lead many IT organizations to lose hours in "analysis paralysis." I've had the opportunity to discuss with reflective organizations (post-trauma), on what they could have done different, and there are indeed many lessons learned.

This is such as huge discussion. And if I wear my Architect's hat, I would say that it's always a trade-off decision -- between changing the way the organization's process works and adapting to the software's way; or customizing areas where the organization has more control in its evolution. At any rate, I can argue that this is not black or white, or a strict matter of choosing one approach vs. the other. The true challenge to my mind, is finding the sweet spot and balance of mixing customized with vanilla (It's tempting to think of ice cream, but please disregard the metaphor). More and more we hear of happy endings for those companies who have used the hybrid approach, and are quite satisfied and at peace with their decisions because they have avoided vendor lock-in where possible, while enjoying out-of-the-box solutions where it makes sense.

I think facilitating such decisions rely on the change perspective of the organization. ERP implementations are really transformative, and there is no escaping the changes such initiatives entail. Trite as it may sound, it is really how the organization makes these tough change-related decisions that drive all other critical success factors.

A current disruptor to ERP implementations has been the cloud initiatives and platform provisioning. This could definitely bring the TCO's down significantly, and would perhaps limit the debate on customization vs. adaptation some more -- but not necessarily in all cases. The Forbes article from 2014 reports on the accelerated migration to ERP cloud. At that time of publication,  the study indicates  the following statistics:

• Only 2% already have core ERP in the cloud, a total of 47% of organizations surveyed plan to move their core ERP systems to the cloud within five years. This is because their ERP requirements tend to be focused around administrative ERP (financials, human capital management and procure-to-pay) where there is a wider range of cloud options (compared with manufacturing).

• In aggregate, 30% of respondents say that the majority of their ERP systems will be on-premises for the foreseeable future.

• 30% of organizations surveyed said they planned to keep the majority of their ERP systems on-premise for the foreseeable future.  Manufacturing organizations dominated this survey segment.

If you notice, most of the early movers do so on those applications which are more-or-less traditionally "vanilla stable."  Laggards, like those from manufacturing, have high to moderate customization requirements, and not surprisingly are perhaps hesitant to move quickly to the cloud.

More details on the study can be found at the reference below.

References:

Columbus, L.(2014 FEB 7). Why Cloud ERP Adoption Is Faster Than Gartner Predicts. Online Article. Retrieved from http://www.forbes.com/sites/louiscolumbus/2014/02/07/why-cloud-erp-adoption-is-faster-than-gartner-predicts/
/