Background
When I first came in contact with SAP XI (version 2.0) about three years ago, I was perplexed with the component called SLD. Within the SAP XI architecture, the SLD maintained information on the participating systems in the integration. SAP XI 2.0 was enabling a simple point-to-point integration broker scenario between two applications, and I was not sure why SAP had gone overboard with the extra levels of indirection and abstraction.
With my knowledge of other middleware products in the market (such as TIBCO, SeeBeyond, IONA, Biztalk), all the middleware products maintained end-point information within their private repository. There were facilities to transport the configuration across development to quality to production systems, but the vendor did not build a standalone repository dedicated towards maintaining the participating systems in the integration scenario.
At first, I did question the rationale of the overhead in maintaining systems (technical, business), products and software components in the SLD, before I realized that it was a brilliant way of modelling the enterprise.
SLD Modeling Principles
Certain key principles are evident by way of modeling your enterprise systems within the SLD:
- SLD maintains a distinction between Physical systems and Business Applications.
- You model both your Physical systems and the Business applications.
- You can represent your non-SAP business applications on the SLD.
- The concept of Products containing Software Components is quite powerful in representing Product build structure and release schedules. This concept is valid for non-SAP applications too.
- You can represent your partitioned landscape in terms of the various tiers such as development, quality, integration, pre-production and production. Partitioned landscape representation is a best practice from the SAP world that would benefit the rest of the technology landscape.
Why SLD
It seemed like the SAP product architects took a conscious decision of building the product called the SLD. They took a long term view of the evolving SAP product portfolio and imagined a not-so-distant future where a customer would have a complex SAP landscape. The customer would definitely need a tool for Solution Management (well, SAP gave us the Solution Manager) and the customer would need a central repository that contained information on what is present in their landscape.
SLD Positioning
What makes SLD more exciting is that SAP embraced open standards in the product development of the SLD. SAP has used industry standards for representing the meta-data within SLD (CIM - Common Information Model), and an open way of publishing information to the SLD.
The implications are enormous. Now, it is possible for you to publish data to SLD from your Java / .NET / XYZ application to the SLD using open protocols.
SAP NetWeaver centric Enterprise Architecture
Technical maturiy and product positioning of SAP NetWeaver has evolved over the last 4 years since SAP Netweaver was announced as a unified brand. In its present state, SAP NetWeaver is being positioned as THE enterprise-wide technology platform. Several SAP Netweaver components could assume the importance of being enterprise-wide Infrastructure components, and SLD is certainly its cornerstone.
Future Direction
So, what is in store for the future ? SAP would add enterprise scale features to SLD to make it a truly enterprise-wide landscape directory (probably, rename it to ELD - Enterprise Landscape Directory ?). You could expect many more attributes being added to the entities being modeled in the SLD, such that all future Solution Management Tools can refer against this central "master-data" repository of your enterprise. You could also expect data-suppliers being made available such that you could publish application status for applications hosted on different technologies (J2EE, .NET, AS/400 etc.)
Next Steps
I would recommend customers that have strategically aligned with the SAP platform for their Business and Technology Platform to plan on how to manage their non-SAP aspect of the lanscape using Unified Tools. However, the starting point for any Unified Solution Management tool would be a common central repository that captures all views of the Enterprise Architecture. I would recommend customers to work towards creating guidelines and best practices for extending SLD as the Enterprise wide landscape directory for their organization.
