Most application architectures are overly complex with too many components and layers. In most cases this complexity is also exposed to developers requiring them to create components in each layer. This creates more work for developers than is necessary as they must design, build and test components in each layer. It also means that developers must understand (be trained in) the intricacies of the architecture.
In the worst cases, developers must specialise in specific layers (technical components) rather than business components fragmenting the business knowledge across multiple developers and teams. This significantly adds to the communication and coordination effort required, increasing project complexity.
When developers are forced to work in many layers, any change or enhancement to the architecture is likely to have an impact on their existing components. As a result, the focus of any change is on minimising the impact on existing components, rather than implementing the best possible solution. This introduces additional complexity and over time, the cost of changing or enhancing the architecture becomes prohibitive.
We believe that the Powered™ Architecture addresses these issues better than any other architecture in the market.
The Powered™ Architecture
The Powered™ Architecture is simple, with no unnecessary components or layers. It is almost totally hidden from developers, exposing only the business and presentation layers. These 2 layers are so simple that developers do not need to understand the details of the architecture or even the underlying J2EE technology. In addition, the presentation layer is so easy to implement, there is no need for technical specialisation allowing the project team to be structured by functional rather than technical expertise.
In the Powered™ Architecture developers only need to create 2 types of components, business objects and panels (forms). There are literally no other components for developers to deal with – no servlets, session beans, entity beans, façades, transfer objects, data access objects, controllers, managers, factories, delegates, etc. This ensures that developers are 100% focused on solving business rather than technical problems, reducing the amount of code that would otherwise be required by up to 95%!
Most other architectures claim this to some extent, but usually fall well short. If developers need to worry about implementing patterns they are not 100% focused on solving business problems. Even data access logic (SQL or EJB QL) divert developers attention away from solving business problems. In the Powered™ Architecture, data access logic is located in a separate layer and is completely handled by the infrastructure (including complex query/search functionality).
Since the Powered™ Architecture is hidden from developers, changes can be made with very little or no impact to existing business components. It is also flexible, supporting fat client and web development, as well as allowing applications to run in 2 and/or 3 tier modes.
"developers shouldn’t need to understand the details of the architecture or the underlying J2EE technology"
"development teams are more efficient when structured based on business rather than technical specialisation"
"developers should only need to be exposed to 2 layers of the architecture: business and presentation"
"developers should be 100% focused on business problems"
"patterns solve technical problems, developers shouldn’t need to understand patterns"