Enterprise and solution architects in large organizations must often master a complex of interdependent applications and enterprise platforms. These platforms include core infrastructures that provide networking, hosting and storage; file and database management systems; integration platforms such as backends-as-a-service (BaaS), enterprise service buses (ESBs) and cloud adapters; application servers; web platforms; and extensible application suites such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). Each of these platforms provide shared components and services that are used by applications or other platforms.
How should enterprise and solution architects keep ahead of application and platform relationships as they change at the speed of business today? Imagine an organization with web and native mobile applications that use services hosted on a BaaS. The BaaS provides always-on services that are loosely coupled to legacy applications with only intermittent availability. To bridge this gap, the BaaS communicates with legacy applications via cache managers that publish and subscribe to message topics on an ESB. The BaaS can therefore deliver always-on services with cached data and robust update capabilities, even if the supporting legacy applications operate intermittently or in batch mode.
Architects can manage multi-platform architectures using repository-based tooling. In order to support broad and consistent use based on established best practices, this tooling should support industry standards including The Open Group Architecture Framework (TOGAF®) and the ArchiMate® visual modeling language. Within the repository, platform architects maintain models that describe the structure and function of their platforms, depict supported patterns of usage, and catalog objects that implement those patterns. Application architects reference those cataloged objects in their models. In this way, using the navigation, analytic and reporting capabilities of full-featured repository-based tooling, architects can capture and explore the relationships between applications and platforms in baseline, transition, and target architectures.
Systematic collaboration and peer review ensures that platform architects properly provide shared platform objects for application architects, and that application architects properly reference those objects. For example, in the scenario described above, the BaaS platform architect would model patterns of service usage and integration, and catalog the available services and interfaces for both front-end applications and back-end cache management. The ESB platform architect would model a publish/subscribe integration pattern, the shared ESB components, and the publication topics used by the BaaS cache managers to communicate with legacy applications. Mobile and web application architects would reference the application services and interfaces cataloged by the BaaS architect. Back-end application architects would reference the cache management services and interfaces cataloged by the BaaS architect, and the shared ESB components and publication topics cataloged by the ESB architect.
By requiring and enforcing the accuracy of interconnected platform and application models, an organization compels architects to work together with rigor and precision. Such integrated architecture development is necessary to realize to the functionality, agility, performance, availability and scalability that organizations expect from their substantial platform investments. Tool vendors can support integrated architecture development by making it easy to synchronize their repositories with platform configurations that specify reusable components, interfaces and services.
How do you manage application and platform relationships in your organization? Please post your comments.
Best Regards,
Iver
[email protected]
