Architecture Archives - Paul on Architecture

Top BPM technologies analysis

One of the biggest challenges with the BPM market is working out which tools are capable of meeting the requirements of your business. Although the term standardisation is thrown around often there is very little that is common between BPM platforms. Selecting a BPM is a major undertaking.

In this blog I will talk about a detailed review I have performed that involved deep analysis of the top human centric commercial players along side a number of open source options to actually see which of this tools could meet the key requirements of a real world Enterprise Architecture. Something the salesman for the commercial products were all nervous about. Continue reading “Top BPM technologies analysis”

Assessing the quality of a website

This blog is a starting guide, for business people, to help them get an understanding of whether their website is designed correctly. It is not exhaustive but hopefully one in a series on this topic.

Note that this blog is my personal view, as are all my blogs, however they are based on nearly two decades of experience in the IT industry.

Although nearly every client I deal with has a need for a website it is interesting to observe that many of them do not have an understanding of whether their website is fundamentally “good”.

The problem is that most people are not familiar with what makes a website “good” or “bad”. Some even believe that as long as it ticks all the boxes for what they wanted in a website then its a good website. Some go by the wisdom of the HIPPO’s. (Highest Paid Person in the room’s Opinion) If they say it should have a purple background with yellow text then that’s the right way to build the website. This is why we see a lot of websites talking about the technical details of a product which are hard to read and totally useless to consumers who simply are trying to find a solution to a problem or idea quickly and efficiently.

Continue reading “Assessing the quality of a website”

The Business Delegate Pattern and Rearchitecting old J2EE Apps

In this article I’d like to talk about the importance of the business delegate pattern which for me has been invaluable in achieving manageable budgets and risk on systems that needed to be significantly upgraded or enhanced.

Firstly what is it?

The tech specs of this pattern can be found here. (note this link has changed and will be updated soon)

http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

In short the business delegate pattern provides a pattern to decouple interfaces from actual business services.

In the J2EE world in particular, it has been common practice for developers to tie business services directly to EJBs. That is you cannot use a business service unless your willing to access it using an EJB call. Although modern frameworks have moved us on from this design, the reality is those systems are not that old and are regularly requiring re-architecture and this becomes a problem point for the architect and therefore for the business.

I’m posting this blog to highlight the importance and value of this particular design pattern in dealing with re-architecture challenges of these types of older systems (particularly EJB 2.0 and older and in those bad old days when EJBs were split into remote and local implementations that demanded different interfaces just because the container was not smart enough to manage this itself.)

Continue reading “The Business Delegate Pattern and Rearchitecting old J2EE Apps”