## Introduction In this post we discuss the purpose of structured systems analysis and design (SSADM) and unified modelling language (UML) and the black-box approach. We look at how documenting the holistic information system can serve as a basis for improvement and action. ## What is a System A system can be anything from a simple amoeba to the global financial system. We define the system by its boundaries, at the point interactions occur, or where data enter or leave. For instance, the human body is a system which takes in water, food and produces waste and heat. Data systems are similar. We can use data in the real world without detailed knowledge of how they’re generated, but a developer must understand internal methods and properties. One can thus refer to objects by their name without considering their internal workings. ### Formal information Systems ![[formal-and-informal-information-systems.png]] When we think of systems, people normally see centralized applications such as an ERP (Enterprise Resource Planning) which operates across the whole supply chain. ![[informal-information-systems.png]] But this is only one facet of business information systems which also include the informal non-structured systems, the verbal systems, the people networks, the satellite and external systems. ### Informal Verbal Systems It isn’t sufficient to implement an accounting system and expect a company to run. People also need methods, and channels to communicate. The central information system is surrounded by informal and unstructured systems. ![[Informal-information-sources.png]] Information networks in the broader sense therefore include the verbal, the coffee machine and water-cooler discussions. It’s the rumour mill, but it may also be where the ‘real’ work gets done. People meeting and discussing informally in the corridors, exchanging information that might never otherwise surface. This informal environment enables open and honest exchanges, where formal meetings, with codes and peer pressure, may make dialogue less so. But the informal systems are also about escalating the knowledge which might otherwise be untouchable. To what degree for instance should we formalize meetings which result in operational decisions? These records may be useful to a newcomer trying to understand company culture. An analyst or manager may look at the causes and effects, or identify remedial actions against the performance of a business area. ![[data-flows-from-meetings.png]] A business information system also includes the escalation and delegation channels such as regular meetings and the communiqués that issue from them, noticeboards, email systems, intranets, document sharing sites, the internet, etc. Many different networks are in play and the importance of crucial information holders is made most apparent when they leave. We should build information systems therefore which encourage and reward sharing and emphasize the importance of the information system to an organization. Focus on tools and methods, on training, brainstorming, cooperation and goodwill. Attitude is crucial to the functioning or dis-function of a company communication system. ### Collaborative Systems Many collaborative systems have come onto the market over the last few years. The first of their kind provided basic document storage and sharing, but we now have applications like Notion to capture and centralize information and allow people to comment on it in context. A shared document can be work in progress, owned by the author, and yet part of a value process. And a centralized document can include version history. These new systems replace intranets which were largely used to push static information, and allow for collaboration around projects and sharing informal and more unstructured information, now integral to a fast-moving business. The challenges are like those of individuals trying to understand the world based on external data: finding trusted sources on which to make decisions. The goal is then to structure internally captured customer feedback, market tendencies, competitor analysis, and to transform lessons learned into practical actions. A collaborative system or document library such as Sharepoint is useful to capture, sort and process the unique value of this intrinsic company knowledge. And if it includes a task system, it will participate in driving value-added action. ## Systems Analysis and Design SSADM (Structured Systems Analysis and Design Methodology) includes concepts such as identifying processes, the context, data flows, and entity models (ERD) to design relational databases. ![[systems-analysis.png]] ### Purpose of systems analysis Systems analysis is to determine how systems operate, the actors (users) involved, the data flows between them, and the processes which communicate or transform data to meet user requirements. > [!NOTE] Thinking about systems > Documenting a system or process requires you to think more deeply about it. > These principles may apply to any domain whether business, educational, political or social. The main aim is to understand how things operate and find ways to improve them. ### Black box approach One of the core tenets in SSADM is the [black box approach](https://www.investopedia.com/terms/b/blackbox.asp) which means that you can describe a system from the outside by its characteristics (boundaries, data flows) without necessarily understanding its inner workings. ![[ssadm-system-boundaries.png]] Unless you want to verify its internal operation, you can know OF a function and ‘call’ the systems’ services without knowing HOW it works, just WHAT it provides. For example, we use many computer systems without knowing their inner workings. Likewise, we have come to depend on certain services in society without knowing how they work. - Water comes out of the tap without us having to be engineers. - We can use a toaster or a radio without having to know how either work. - We don’t need to know everything about a peanut before appreciating peanut butter. It may be sufficient to know that ‘the production system’ produces widgets. But an analyst will want to understand its inner workings, if they’re trying to solve an operational problem, or change an aspect of the system. ## Universal Modelling Language (UML) UML is a visual language, using symbols developed by information workers to describe concepts, links, data flows, actors, and processes to model system functionality. It’s a useful way to communicate business models visually to support consensus between implementation experts and those with full knowledge of the requirements. The quality of the system depends on their understanding, and visual documentation can be more readily understood by both. ### Visual Modelling Visual models are often underestimated and underused. Convention requires words but many a concept, database, or project could be summarized with a diagram. The complexity of information systems is a good reason to use visual tools to describe them. A graphical notation uses symbols that have the same meaning throughout. A stick man means a human or systemic actor, an oval indicates a use case, square boxes mean processes. The symbols are consistent, and mean the same thing wherever used. Wherever possible, use a graphical tool to promote the universal understanding of such descriptions. Systems are more complex than ever. Visual documentation helps provide clarity and readability, essential when communicating, reducing ambiguity and saving time. Visual diagrams improve communication and understanding of complex ideas. ![[common-uml-symbols.png]] ### Mind mapping Mind mapping is a very useful technique that can also be used to sketch out the elements of a system and to collect detailed information in discussion with users. The visual arrangement is ideal to gain new perspectives and brainstorm solutions to systemic problems. ![[uses-of-mindmapping.png]] ### UML examples of systems *A use case diagram This use case describes how users use water and where it comes from in the [[Case Studies in Systems Analysis using UML#Water Distribution System|Water Distribution System]] model. ![[water-distribution-system-use-case.png]] *A sequence diagram* This sequence diagram shows the data flows between patients and health care professionals in the [[Case Studies in Systems Analysis using UML#French Social Security System|French Social Security System]] model. ![[patient-relationships-sequence.png]] *A data model*: This data model shows data relationships between suppliers of services and customers in the [[Case Studies in Systems Analysis using UML#Service Site Model|Service Site Model]]. ![[service-site-ERD.png]] *An activity diagram* This activity diagram shows the order of water treatment activities in the [[Case Studies in Systems Analysis using UML#Water distribution system|Water Distribution System]] model. ![[water-context.jpeg]] ## Documenting systems Systems documentation can be an aid in internal training or induction of new employees, and helps to ensure knowledge retention. One aim is to provide facilities for information sharing, to avoid information islands, and provide a record of how a procedure or business area works, thus minimizing disruption when a person leaves the organization. Documentation can serve as the baseline for change management. If the organization describes all its systems and processes using the same notation, it can create a coherent overview of the whole information landscape. Understanding the impact of systems can help to determine whether operational systems are effective, and which parts need to be updated. The success of an organization may depend on the efficiency of its information system, and changing conditions drive changes to systems. Documentation therefore needs to keep up with the evolving business. Interfaces can’t be completely mapped without an understanding of the system as a whole. Systems analysis would also need to include satellites such as groupware which might apply personalized rules different from the central system. Documentation might then include informal verbal systems, the communication networks that exist between colleagues, and ask whether they’re efficient, and based on correct information. The objective is to look at where functions overlap, plan new applications, which exclude or remove duplicated features. ### Analysis to Manage Change The main issue in systems development is the translation of business requirements into technical specifications and working software. Business people may lack expertise on technical matters, and technicians don’t always master the business process. This is why we do functional requirements' analysis. The risk of wasted resources, time and the number of failed projects justify the need for project control. However, systems analysis is the key to development and design. It’s best to have a strong base and do things in order, rather than modifying the foundations after construction of the walls has started. It’s much cheaper to rethink and redo a design than rebuild a house. In software development, there are diverse approaches such as the waterfall method (iterations), test modelling, the Microsoft change management method, and the Agile method. In Agile, requirements are gathered by ‘talking to the users’, and creating working software. The Agile method is less focused on documentation, which might take time, and be obsolete very quickly, depending more on personal understanding of the requirements by the development team. The approach is to talk about the software model with users and improve it in the next cycle. ### Requirements analysis Requirements analysis is where you determine what functions are needed in software to fulfil your business needs as part of [[Steps to Define Projects and Protect the Plan#Defining projects from the bottom up|project definition]]. ![[mindmap-requirements-analysis.png]] Some companies have separate systems in different parts of their business. They may have one system for order planning and a different one for research and development. But now, transactional management, CRM, manufacturing, inventory management and accounting can all be in one ERP system. > [!NOTE] Remark > It’s important to choose the correct software to get the job done. Choosing the right software depends on analysing the business processes involved. Multi-layer database systems (forms and queries built on tables and relations) function best with well-designed data structures. Once built they may be difficult to modify. It’s worth getting a good understanding of the requirement and the business case before embarking on designing and building. The software development process (coding, infrastructure, technical choices) includes project, service and quality management, with several levels of control, which raise costs and increase overall system complexity. But it’s important to manage change in a controlled manner, and many factors can influence the need for change, most notably markets and external environments. ### Documentation for Memory People don’t always recall details accurately and our memory often plays tricks on us. This is where databases serve their purpose: memorizing, whereas the brain is good at thinking and making connections. You can help this recall process by recording, categorizing, linking and [[Issue Database as part of the quality process|managing issues]], events, memories and experiences in a database, to help you and your organization learn from experience. This data can then be used to [[Sort Ideas into Actions and Projects]]. A vision of information flow in the organization will help to understand whether systems are adequate, whether they function ‘properly’ and whether any part of the informal system should be formalized. To do this accurately and cost effectively, they need to be documented, or at least widely understood. Documentation enables discussion, debate and decision-making. While useful to store for reference, such a flow map is most useful when talking about how to improve productivity.