• hard to maintain because ad hoc, hand-crafted solutions don't usually follow a clear architectural concept throughout the system architecture;
• hard to evolve or change because ad hoc, hand-crafted solutions usually lead to tangled code spread out over the system with many difficult-to-resolve dependencies on other components;
• hard to reuse because ad hoc, hand-crafted solutions often involve special-purpose code added into the systems at several places; and
• hard to understand because tangled code added in several places offers no adequate separation of concerns.
• Internal business policies. The business side might require specific internal policies to be fulfilled throughout an organization's systems. For instance, a financial institution might set a policy that business transactions over a certain limit require segregation of duties (having more than one person required to complete a task; often called the four-eyes principle), so if one trader carries out a transaction, another trader approves it before it is processed.
• Internal IT policies and good practices. The software engineering field often follows its own IT policies and good practices, such as those found in coding and documentation guidelines, as well as in guidelines for change management, configuration management, and deployment management. Note that some of these kinds of guidelines are not only prescribed by internal policies but also appear in the IT standards that enable the implementation of certain regulations.
• Security policies. A business might have specific security requirements that are pervasive throughout the whole system. Quite often, the business requirements for security overlap with regulatory requirements such as those in the payment card industry.
• QoS policies. A business might require compliance of the runtime infrastructure to a certain quality of service (QoS), such as a specific performance window, a maximum latency, a particular mean downtime, or a certain throughput. This can be due to the necessity to fulfill contractual agreements such as service-level agreements (SLAs).
Uwe Zdun is a full professor of software architecture on the faculty of computer science at the University of Vienna. His research focuses on architectural decisions, software patterns, service-oriented systems, domain-specific languages, and model-driven development. Zdun has a PhD in computer science from the University of Essen. He is editor of Transactions on Pattern Languages of Programming and associate editor in chief for design and architecture for IEEE Software. Contact him at email@example.com.
Ayse Bener is a full professor and director of the Ted Rogers School of Information Technology Management at Ryerson University. Her main research area is empirical software engineering. Bener focuses primarily on the problem of decision-making under uncertainty by using machine-learning methods to build predictive models, cognitive science to model human behavior, and game-theoretic models to determine strategies. She is a member of IEEE, IEEE Computer Society, ACM, and AAAI. Contact her at firstname.lastname@example.org.
Erlinda Olalia-Carin is a partner in the advisory practice of KPMG Canada. Her research interests focus on the identification and mitigation of risks associated with the use of technology, especially for systems supporting financial reporting processes. She is KPMG Canada's National Service Line Leader for controls attestation and service organizations controls reporting. Contact her at email@example.com.