This article places focus on architecture tips for you and your web applications. Today’s organizations are either using a combination bricks and mortar and web interface with customers, or they are likely creating in house web applications that never leave their firewalls. In either case, architecture is just as important as ever.

I would like to focus on application security for a moment. If you are fortunate enough to receive your marching orders direct from business strategies and have built a business architecture, it might contain strategies and processes that include devolving data and services over the internet to customers. Before you hand over the keys to your golden city, which seems to be hardest in municipal and regional government run organizations that have had their hands forced by the freedom of information acts, you must review and update your underlying architectures.

There is a great need to secure the data in your web applications. Consideration must be given to who sees what, what is hidden from whom, you know the drill. The business wants you to hand over access to data and applications that have been safe inside the walls of your organization for years. They said “information and services” must be available to the customer.

Developers are typically focused on the features and interface of this data and security is usually the last step in the design process, if you are lucky or as the last point in development if you are typical. If you concentrate on the main domains of Enterprise Architecture, determine the security requirements the business is demanding, and review and update your architectures to ensure data is secured in the appropriate manner, the application is secured with appropriate access and services, and that the technology architecture which will house these applications and services are ready and depict your fortress.

Why is this hard? Organizations buy web applications that are usually custom built or they build them themselves. Often security in house is not handed to a security expert, or purchased applications have one perspective in mind, and you don’t know what they were thinking when they designed it themselves. Often purchased applications are built and sold for one purpose, and are then morphed to leverage the seller’s investment and you can’t be sure it will be secure enough to do what you want it to do.

Developers are focused on making their code run, getting the major bugs out and getting it out the door. They typically pay lip service to the security, unless that is their main interest. Organizations need to dedicate specialists to this particular area, or if this is not a main core competency, hire those who do this to do an audit.

Even better – organizations should build frameworks in which they develop, hone and specialize their security approach for all applications, and then have it audited and tuned. Software development kits are now sold that have even better features to allow developers and designers to see where they are vulnerable. Effort in this regard should be tied to this employee’s performance, so that the importance of it is elevated.

Finally, as the architect, you will need to draw some pretty decent diagrams to show how you are planning to keep gremlins out. My suggestion – take a deep breath, focus on your layers, and draw several diagrams – one for each domain, because you will be asked, how your applications are being secured, and you should leave no stone unturned when it comes to web applications.