Application Architecture

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other fundamental applications – they are most valuable when …

Packaged Applications (such as PSFT, eBiz, etc…) are the very operational heart and soul of most companies.  Whether it is human capital management, logistics, sales, or any number of other fundamental applications – they are most valuable when they are customized to fit YOUR business and integrate with YOUR systems.  The problem is that these customizations and integrations are most often done with built in (proprietary) tools or using things like PL SQL, batch files or other less-than-optimal (often proprietary) solutions.

Enterprise Architecture steps in at this point because the move from one major version to the next is a major undertaking for most companies; one that takes month (sometime as much as a year) to plan and implement.   When the applications have been customized to meet the business’s requirement, these very customizations make upgrading more complex.  One of the tasks of EA is to establish guiding principles which help shape decisions at every level of the architecture.  One key principle here is “Keep COTS Packages as Vanilla as Posible” – meaning do as little customization as possibly directly in the application itself.  The more vanilla the application is kept, the easier it is to upgrade.

It is a best architecture practice to place these customizations in the middleware layer where standards such as Java, Web services, XML, and the like mitigate the risks of using proprietary technology.  They also provide a more comprehensive and faster-development-lifecycle framework for integrating with the entire corporate IT ecosystem while greatly enhancing the possibilities for service/integration reuse.

So, with all that being said, a common question I get is “OK, where do we draw the line between using the built-in tools vs. using a middleware layer?”  This chart helps answer and provides delineation between the reasons to use one approach over the other.  Though not exhaustive, it should provide a framework for figuring out which customizations/integrations should go where.

Well, I passed the TOGAF Certification Exam.  Super happy.  Here is some advice that I passed on to someone who saw my previous post:
I recommend the class led by Architecting the Enterprise.  That will get you familiar with the materi…

Well, I passed the TOGAF Certification Exam.  Super happy.  Here is some advice that I passed on to someone who saw my previous post:
I recommend the class led by Architecting the Enterprise.  That will get you familiar with the materi…

Well, I am one week away from going for my TOGAF certification.  For those who are also going for your certification and want some additional prep, I found two sets of additional questions for Part I and Part II (scenarios) of the test.  Chec…

Well, I am one week away from going for my TOGAF certification.  For those who are also going for your certification and want some additional prep, I found two sets of additional questions for Part I and Part II (scenarios) of the test.  Chec…

So yesterday the follow-worthy @chrisonea lobs this question on Twitter:

Is there any circumstance under which IT should build a thing without a business purpose?

I emphatically answered, NO. Here’s why.

Long ago when the…

I just perused Mr. Allega’s (Gartner) recent article on the legal quagmire that is stirring around the Zachman brand, framework, and its two proponents. It is too bad such a pair of thought leaders will end their careers in such a manner. Upon reading …