mono\u2022lith\u2022ic adjective \\m\u00e4-n\u0259-li-thik\\<\/p>\n
1. a: of, relating to, or resembling a monolith : huge, massive…<\/p>\n
2. a: cast as a single piece <a monolithic concrete wall> b: formed or composed of material without joints or seams <a monolithic \ufb02 oor covering> c: consisting of or constituting a single unit<\/p>\n
3. a: constituting a massive undifferentiated and often rigid whole <a monolithic society> b: exhibiting or characterized by often rigidly \ufb01 xed uniformity <monolithic party unity><\/p>\n
Extract from <http:\/\/www.merriam-webster.com\/dictionary\/ monolithic><\/em><\/p>\n SAP is a leading provider of enterprise application software. Nearly 65 percent of the world\u2019s \ufb01nancial transaction revenue involves SAP software somewhere along the way. Traditionally, SAP\u2019s offerings such as SAP Customer Relationship Management or SAP ERP (SAP Enterprise Resource Planning) have not only been applications, but also end-to-end business suites: stable and reliable but at times also massive in scope and complexity, with major releases sometimes supported for twenty years and more. Monolithic may have been the word that came to mind when many people thought of SAP products.<\/p>\n A few years ago, SAP expanded its offerings in \ufb01ve market categories: applications, analytics, mobile, database and technology, and the cloud. SAP is accelerating change as the IT industry undergoes a structural shift toward investment in software-based innovation. Legacy products were broken up to be more nimble and release faster. Big data, cloud computing, mobility, and social networking present a signi\ufb01cant market opportunity for SAP. Additionally, acquisitions complemented SAP\u2019s organic growth and boosted SAP in speci\ufb01c areas of strategic interest.<\/p>\n The challenges of SAP\u2019s new product strategy were\u2014among other business units\u2014evident in the Technology and Innovation Platform (TIP) unit, the unit that has been developing SAP NetWeaver, the platform for SAP\u2019s classic product portfolio. SAP NetWeaver documentation was as monolithic as the platform itself. The core documentation for a single release contained some 50,000 information objects, at delivery strung together and interlinked in a single massive HTML library.<\/p>\n Five major SAP NetWeaver releases, with dozens of support packages, would eventually be supported concurrently, and proliferating code lines had created a byzantine evolution of content across the documentation set. What a challenge for product documentation, then, when SAP NetWeaver\u2019s software components began to be decoupled, bundled in varying subsets within the larger platform, with asynchronous delivery cycles and, in some cases, shared components. The only way to deliver documentation was to componentize the documentation into sets mirroring the software components. If the linking binding them together could be reduced, they could be shuf\ufb02ed and re-packaged just like the SAP NetWeaver products.<\/p>\n Componetization began with the de\ufb01nition of a basic architectural model to re\ufb02ect the platform\u2019s software components, their hierarchy, and dependencies. SAP NetWeaver documentation was then segmented into dozens of building blocks, arranged in logical architectural layers from highlevel products, through their components, and down through application servers to databases. Information developers then spent months combing through their content, grouping topics into smaller subsets (one of which, nonetheless, contains 30,000 objects in two languages) and excising links that didn\u2019t re\ufb02ect product dependencies, to render their content more manageable in changing contexts.<\/p>\n Componentization wasn\u2019t SAP NetWeaver\u2019s only challenge, however. Analytic applications from BusinessObjects, a business intelligence \ufb01 rm that SAP acquired in 2007, began to integrate with products from the SAP NetWeaver portfolio. Shortly thereafter, a major upheaval emerged from within the TIP development unit: a revolutionary, in-memory platform called SAP HANA, which speeds up data transactions and analysis so radically, that in short order it became the foundation of SAP\u2019s technology strategy. From the start, it was delivered with SAP NetWeaver and SAP BusinessObjects components, but was slated to be associated with further SAP offerings.<\/p>\n Within the TIP knowledge management unit (TIP KM), the once monolithic world of SAP had become a vast set of juggling balls, pins, and hoops, any combination of which might need to be kept up in the air at once. TIP KM was challenged to meet the product roadmap across two different environments and even more source \ufb01le formats, with SAP NetWeaver in Microsoft Word and propriety XML in SAP\u2019s legacy content management system, and SAP Business Object\u2019s Darwin Information Typing Architecture (DITA) content in another legacy content management system (CMS), in which key components were shortly to be deprecated.<\/p>\n The roadmap was only going to involve more integration and diversi\ufb01 cation. So in 2012, in an effort to optimize, align, and unify all product documentation into a single content management solution, we made the decision to consolidate across the TIP unit, on DITA 1.2, in a new third-party CMS.<\/p>\n Our primary requirements for the new CMS were these:<\/p>\n This model contains thirteen layers:<\/p>\n The dependency tree also de\ufb01nes linking rules:<\/p>\n This model is designed to work for releases of any scope, from sprawling and complex SAP NetWeaver releases, down to the standalone product SAP BusinessObjects Explorer, whose content is contained in a single container. When we looked for a new content management system, support for this content architecture model was a priority.<\/p>\n The CMS evaluation resulted in our selection of IXIASOFT DITA CMS solution from Montreal-based IXIASOFT not the least because of IXIASOFT\u2019s elegant response to this requirement, using standard DITA. IXIASOFT\u2019s solution reposed upon extensive use of the DITA 1.2 keyref feature:<\/p>\n DITA 1.2 introduces the \u201ckeyref\u201d feature which provides an indirect addressing mechanism. You can use \u2026 keydef elements (new with DITA 1.2) to de\ufb01ne keys in a DITA map. Topics can now be given a symbolic name (keys attribute) that points to a topic \ufb01 le path (href attribute). Future references to such topics are made using a key reference (keyref attribute). At a later point in time, if the topic is relocated, the path needs to be updated only in the map where it is de\ufb01ned. All other references will automatically pick up the new location.1.<\/p>\n In our implementation, all references created between content objects would be indirect: keyrefs instead of hrefs and conkeyrefs instead of conrefs.<\/p>\n Containers are de\ufb01ned using specialized DITA maps (container maps) that use keydefs to reference all the objects (content maps, topics, and images) that \u201cbelong\u201d to the container. Object IDs 1 Extract from \u201cDITA 1.2 feature article: Keyref overview\u201d by Sowmya Kannan (http:\/\/dita.xml.org\/resource\/keyref-overview-dita-12) are used as each object\u2019s key. Each container is associated with an architectural layer, whose numerical value is inherited by all objects belonging to the container to support checking of compliance with linking rules.<\/p>\n At the beginning of a product release cycle, information architects de\ufb01 ne required containers or create new versions of existing ones, simply by cloning the container map. They then model the dependencies between the containers, establishing the dependency tree for the release. Dependencies between containers are created simply by dragging the child container and then dropping it into the parent container in the CMS interface. This creates a mapref from the parent container to the child. The dependency tree in Figure 3 (on page 4) refers to the global set of content with potential relevance for the release. Once a project\u2019s containers and dependency tree have been set up by information architects, authors are ready to begin their work. Shielded from the complexity of information architecture requirements, they can work in much the same way as authors working in a DITA environment using standard hrefs.<\/p>\n Content maps are specialized DITA maps that, like classic DITA maps, de\ufb01 ne the structure of topics, images, and submaps in a deliverable, but using keyrefs instead of hrefs. In addition, each content map references a single container map (to which it is said to belong); the keydefs in the container map, and those beneath it in the dependency tree, provide the resolution for the keyrefs in the content map. References are resolved in real-time in the CMS environment and the oXygen editor so that as soon as an author adds a topic to a content map or a link to a topic target, titles are displayed instead of their keys.<\/p>\n The keydef\/keyref mechanism also enforces the linking rules established by the information architect in the dependency tree:<\/p>\n Each version of a container map references the versions of topics that are relevant for that container version. When you create a new version of a container, you create a new container map, with the same key de\ufb01nitions, pointing to the same content objects but without creating copies of the objects themselves, as in classical branching approaches. Since content maps use only keyrefs to reference objects, they don\u2019t require manual adjustment to pull in updated objects. They rely on their container to provide the speci\ufb01c version of the referenced objects. To create Version 2 of product documentation associated with a single container, Container_A_v1, an information architect clones the container.<\/p>\n When authors begin to work on the content for the new release, they simply open the cloned v2 content maps and work from there. The content maps automatically reference the new version of their associated container. At this point, all topics and images are shared between both container versions. Authors can decide whether they want their modi\ufb01cations to apply to both versions or branch an object to make modi\ufb01cations in one version only. Branching creates a new physical version of the object, with the same ID (key) but a different version. Its reference in Container A v2 is automatically updated. In this case, all content maps in Version 2 will automatically use this new \ufb01le\u2014without any action from the author\u2014because the keyref they contain now points to it in the container.<\/p>\n In this way, speci\ufb01c versions of containers are gradually updated with references to updated topics, but references to topics that haven\u2019t been changed remain the same. If you need to create new maps or topics for Version 2 of this product, you simply associate them with Container_A_v2 at creation and set their version from the beginning to v2. Thanks to indirect linking, no existing links are broken when you move to the next version of product documentation and no manual updating is required. And thanks to the features designed by IXIASOFT to support this container and versioning model, authors manage versioning with ease.<\/p>\n The advantages of indirect linking are also underscored when software components are removed from their traditional contexts and bundled with different product stacks. The information architect determines the containers with relevant content for the new project. For containers whose content will be updated, a new container version is created.<\/p>\n The information architect then models a new dependency tree using all the relevant containers, arranging them into a hierarchy according to the common architectural layering model. When documenting the new release, authors either modify existing content maps (documentation deliverables) or create new maps associated with the updated container versions. Linking rules and resolution are de\ufb01ned by the new dependency tree. Any pre-existing references to topics that don\u2019t belong to the current dependency tree are automatically \ufb02agged as unresolved. And because we will largely limit linking to relationship tables, unresolved links can easily be \ufb01xed\u2014or simply not rendered in output.<\/p>\n TIP KM released its \ufb01rst customer-facing product documentation in November, 2012, just eight months after our decision to go with IXIASOFT DITA CMS. The SAP NetWeaver documentation set is in the process of migration, and by the end of the year, the documentation content for a recent acquisition, Sybase, is intended to move into the new system. Already mostly in DITA, it \ufb01ts right into our model. We are DITA-compliant. We can version simply and elegantly, without redundancy. We can support the evolution of our products. We are in a good place.<\/p>\n\n\n Priscilla Buckley mono\u2022lith\u2022ic adjective \\m\u00e4-n\u0259-li-thik\\ 1. a: of, relating to, or resembling a monolith : huge, massive… 2. a: cast as a sing…<\/p>\n","protected":false},"author":26,"featured_media":23240,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[44],"tags":[],"class_list":["post-23234","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles"],"mb":[],"featured_image_urls":{"full":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",1890,1417,false],"thumbnail":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1-150x150.jpg",150,150,true],"medium":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1-300x225.jpg",300,225,true],"medium_large":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1-768x576.jpg",768,576,true],"large":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1-1024x768.jpg",1024,768,true],"1536x1536":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1-1536x1152.jpg",1536,1152,true],"2048x2048":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",1890,1417,false],"ultp_layout_landscape_large":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",1067,800,false],"ultp_layout_landscape":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",760,570,false],"ultp_layout_portrait":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",600,450,false],"ultp_layout_square":["https:\/\/www.ixiasoft.com\/wp-content\/uploads\/2015\/09\/BP-NewsSAP-1.jpg",600,450,false]},"post_excerpt_stackable":"New Product Strategy<\/span><\/h3>\n
Componetization<\/span><\/h3>\n
We Need a New CMS<\/span><\/h3>\n
\n
\n
\n
Our Solution<\/span><\/h3>\n
Containers<\/span><\/h3>\n
Content Maps<\/span><\/h3>\n
\n
tree, simply doesn\u2019t resolve, and is \ufb02agged by the CMS.<\/li>\nVersioning<\/span><\/h3>\n
\n
Bundling<\/span><\/h3>\n
Conclusion<\/span><\/h3>\n
AUTHOR<\/h3>\n\n\n\n
SAP<\/em><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"