The organisation that I currently work for re-visited its application development standards recently. The approach used was to agree on the “Principles” that development should adhere to. From these principles some detailed Standards were then developed to guide the development of code. This detail might include some checklists that can be used to guide developers in the design of their code. But beware!! These checklists should not be applied only at the quality assurance gates (i.e. when code gets implemented in Production), but rather right at the start of code design, so that adherence is not an after-thought but becomes a way of life for project teams.
I recently showed examples of graphs that depict how an application might conform to standards. I consider the concept of conformance as an important part of an Application Architecture. Conformance is also a key element in the practice of Enterprise Architecture. If an organisation wants to progress from its current architecture to a future state, it has to govern the development projects that are run to ensure there is no deviation from the end goal. Even if it does not plan to be in a different place in future, it certainly wants to uphold certain standards for the sake of quality and managing risk to the business. The next few posts will discuss application standards.
The project that I’m working on currently, is deploying a solution that makes use of no less than 7 integration methods. This time I cannot provide examples as the solution is confidential. I developed 7 different views of the integration using exactly the same basic diagram that depicts the various components of the solution. Each view however only shows the integration paths that use that specific method, e.g. MQ Messaging paths are shown seperately, so is the integration using SOAP. From an MQ point of view this is useful for the analyst who is responsible for MQ deployment and the maintenance team who looks after MQ in Production.
Standards such as COM/DCOM, CORBA, EJB (Enterprise Java Beans),
and XML work to assure that applications can communicate easily.
Components written to the same standard can interoperate, but mixing
these technologies results in an environment that requires another level
of integration (usually more adapters). Microsoft’s COM allows two
applications running on the same computer to communicate easily, but
CORBA and EJB are better suited for applications operating on different
computers. While CORBA is a messaging specification, products that
implement it (object request brokers, such as BEA’s MessageQ and
IBM’s MQSeries) are not. Some variants of the standard may be more
difficult to implement than others, and most do not communicate freely
Modern applications, when deployed in a distributed environment, rely heavily on integration methods to communicate to databases and user-facing frontends. Large organisations typically have application landscapes that span various platforms and environments, especially where legacy applications are still being maintained. The application architecture of an end-to-end solution can therefore include some views of integration methods.
Here’s an example of an Application Architecture view that will actually be of value to a variety of audiences. It features the different levels of a “top-to-bottom” solution along the lines of the EA framework that I shared in earlier blogs. At the top the users and roleplayers are shown as well as the channels they use to interact with the solution. On the next layer the business processes are shown that happen to be automated by this solution. The next level down shows the components or application “services” that make up the solution and the bottom ones show the infrastructure services and hardware that support the solution.
Management and Architects are likely to require Application Architecture views that show an application’s lifecycle (is it ageing, or when is a review required of its continued suitability), costs of supporting and running it and the dependencies on 3rd parties such as a vendor for support and future releases. Views that compare an application or application suite to other products available, or scenario’s to redevelop it in-house if it is nearing end-of-life, will also be of value to audiences that operate on a decision-making level in the organisation.
We’re still on the topic of Application Architectures and the various views that one can develop for this domain of Enterprise Architecture. Different views will be of value to different audiences (e.g. Management, Business Analysts, Solution Analysts, Developers, Architects, etc.). For a BA it’s likely that views are required that show an application’s business functions, the processes it supports and instructions on how to operate the application.
The attached graph is the 2nd of 2 examples that show how an organisation can measure its application portfolio against a set of standards. In these examples 10 standards are each measured with a simple score out of 100. This graph shows the 10 standards and the footprint across 20 applications for these standards.
An organisation may wish to see some concolidated views of how their applications measure up to standards. In the next 2 posts I will show 2 graphs that I helped develop for an organisation. These 2 examples were created using a spreadsheet that scores 10 criteria for 20 applications on a percentage scale. Graph 1 attached here shows the “before” and “current” footprints for the 10 questions across the 20 applications.