Today’s short blog, the first for 2024, derives from recent work in which I required a classic Table of Contents (TOC) for a Solution Design( SD ) Document/ Artefact. To create this TOC, I began by listing elements one would expect to see in the artefact i.e. primary section headers, which is challenging when you consider the ‘ purpose’ of the document, and the target audience both of which impact the overall structure of the document. For most artefacts, it would be prudent to tailor the SD to meet the needs and challenges of the specific problem. For example, a basic SD for a new in-house development may be very technical, especially when the target audience may be the Systems Community ( Developers, Testers, Service Management etc.) and resulting in an artefact with the content and focus on Component Views(Building Module Blocks) , Deployment Views and the Runtime Operations . So, when I considered the elements for the SD Artefact I wanted...
The following appeared on my previous blog site on January 6th 2014 and received in excess of 16K hits per annum - so reposting on new site. Earlier today, while reviewing a document I produced some time ago, I discovered a useful Non-Functional Requirements (NFR) checklist and thought I would simplify , ‘repackage’ and share via this blog. NFR checklists are not unique products, they are easily found on the web with numerous examples available for reuse, one such example can be found at the Open Group’s website under the ToGAF Requirements Management section. Most of you are probably familiar with NFR’s – However if not, you can consider them a set of requirements/criteria used during the run-time operation of a system and not the specific behaviours that the system must exert. The NFR’s vary in importance and are usually aligned to the context of the system e.g. Operational Safety could be classed as a NFR, especially when working in hazardous conditions (...
It is essential for those charged with the support, management and delivery of technology capabilities for an organisation to be fully conversant with its Business Operating Model (BOM). BOMs, as one would expect, are not standard across industries. They evolve when the organisation transitions and develops as is the case in dynamic service-based industries, such as professional services, where organisations are constantly looking to repeat and generate new revenue streams. The current state of BOMs for professional service firms, although dynamic in nature, do exhibit mutual patterns across industries and using the global law firm example we highlight how capabilities across these firms are quite common . Law firms that have a global footprint can serve large global organisations that require advisory and legal services across multiple jurisdictions. The Business Operating Model (BOM) for the majority of the global law firms is quite unique, primarily due to specia...
Comments
Post a Comment