Why Architectural Governance Matters
We had a project recently where we have been updating an existing Java application and moving it from JBoss to WebSphere. Now some of you millennials may start thinking this is a backwards move, but its not. It is not one that I am working on, but rather something my colleagues are. Follow me on this. Here is the background:
In this application are servlets calling out.println(“< table > …..< /table>”). There are JSPs that accesses properties files on the server and makes changes to those files on the fly – an absolute security risk, which WebSphere (rightly so) will not allow, but JBoss treated with indifference. This is why the move to WAS is not a backwards move. There are Spring and Hibernate components, yet very poorly implemented, especially since they are mixed with the criminal acts listed above.
Now, I can’t name the client, or the project, but let’s say its an important one. That said, an architectural review would have found many of these errors and prevented having to hire an outside firm to come in an re-engineer the application. When we are done, the app should run on ANY JEE application server, be secure, and perform well. This brings me back to the topic of my conversation. Architectural Governance is about establishing the frameworks and standards across your enterprise. The trick is to do it without hindering creativity (which in turn makes your organization less agile and responsive).
One way to begin implementing Governance is using IDE generated models. By this I mean creating patterns and templates that codify your standards and frameworks, that can then be used by your architects or designers to generate applications or application stubs.
For example, let’s say that you choose to create a standard way of creating a JSF/SEAM/EJB application, and you want that combination of frameworks to be your common choice of frameworks. By creating patterns, which establish how the frameworks are used (including features such has caching, security, and logging), you make it easier for the designer/developer to write the application and GUI. Your models and patterns can also establish a common taxonomy and nomenclature – meaning how your Java classes are named and packaged. By having a common naming structure, you make all your applications across your enterprise easier to manage, and reduce the risk that your only source of domain experience (the developer) walks out the door (quits) or gets hit by a bus.
Also, by establishing Governance at this level, you make it easier to migrate to future releases of frameworks – once you update one application, the next one should be mostly a repeat of the first. For organizations that are bound by regulatory or legal requirements such as Sarbanes-Oxley, or HIPPA, Architectural Governance makes compliance much easier (or at it makes non-compliance uniform throughout, which is easier to fix than it would be on a heterogeneous architectures).
Now for those who cringe at the thought of working in such an environment because you’re afraid it may strain your creativity, remember that good communication in a development team should allow you to show your creative side. Its a balance in the enterprise. Small business can play fast and loose with their architectures, but enterprises are larger targets for litigation, and the risk of poor architectures are multiple.
Soon I will post a blog on RSA, and how it can generate patterns and templates for enterprise architectures.
