“Simplicity is the ultimate sophistication.” ― Leonardo da Vinci
Either from architectural design, engineering discipline or management perspectives, simplicity means or is related to too many things such as manageability, availability, scalability, flexibility, reliability, robustness, sensitivity, comprehensiveness, speed, responsiveness, etc. And like many things, there is good simplicity and bad simplicity; good complexity and bad complexity; good flexibility and bad flexibility. etc.
Modern businesses become over-complex every day, they also add to such eco-system complexity! If we accept it is complex, somewhat unpredictable or not completely predictable, we have to accept uncertainty. We all model our complex worlds to decide strategies to meet goals; the only problem is when we take our models too seriously. So, what are the principles to follow in pursuit of just the right simplicity?
1. An Elegant Way =Make it as Simple as Possible, but not Simpler
Everything should be made as simple as possible, but not simpler. -Albert Einstein
Simplicity has a multitude of perspectives: What “the simplicity” is referred to? Is it “the simplicity from a programmer’s perspective” or “simplicity from a user perspective” or “simplicity from solution life cycle maintenance cost perspective”., etc. Simplicity is a multi-dimensional pursuit in an elegant way.
- Is 'elegance' such a word to convey “just right” simplicity? We have all seen tough problems solved elegantly while at the same time admitting that depending on your perspective it may have been very complex for someone to implement. You know an elegant solution when you see it. Like all things in Architecture, Simplicity has always been one of the goals. When you get it "just right" it's called elegant. And the complexity of the solution is simple enough when it only just exceeds the complexity of the problem.
- K I S S –Keep It Simple Principle: When creating a definition, one must not forget the purpose of the effort. The purpose is always to convey information. As a matter of course, comprehensible information includes three different views of the same: structural, behavioral, interactive - In other words, in order to best understand a subject, one needs to define the subject in terms of:
a) Structural view- what it is comprised of
b) Behavioral view - how it behaves (upon application)
c) Interactive View - what contexts it is used in (and the behaviors evoked)
- Simplicity is an aspect of “appropriate” abstraction. That simplicity is a characteristic of architecture promulgates the view that architecture is a 50,000 ft view when it is quite the opposite. This complex mosaic of the inter-related concepts that make up an environment is far from simple. But EA is also abstract, so that, even though the inter-relationships of all aspects of the enterprise are characterized, the details of the individual pieces are left up to the design and implementation efforts of the subject matter experts in each respective area.
2. A Clarified Way –Master the “CRAMPS” Factors
SIMPLICITY may either refer to an architectural constraint OR to a business requirement. When people use the word "simplicity", they are really talking about a kind of transparency or clarity. For example clarity of intent, what business problem is a project funded to solve? What is the purpose of a component? How are responsibilities allocated to various architectural "layers" or management/engineer disciplines?
- There is a relationship between Simplicity and Clarity: With simplicity, what we are adding is clarity & purpose. Removing complexity (assumptions & dependencies) more clearly reveals the intentions of the architecture and its purpose. Things are easier to adapt/evolve not as a result of any "flexibility" that was put in, but as a result of what was explicitly left out (and how it was left out). Certain aspects of the problem space may be inherently complex.
- Solving Complexity Puzzle by Mastering “CRAMPS” Factors: The reason many would have simplicity but act complexity is that they don't know HOW to make it simple. Analyze “CRAMPS” factors, the actual order in which factors are assessed is:
1). Performance — what is the expected performance for the solution, is it within acceptable limits.
2). Availability — what availability is required for the application system, and does the solution provide it. Reliability, Robustness part of Availability Sensitivity, depending on how you mean this, it is an aspect of Availability, Performance
3). Scalability — What is the scalability of the solution, is it within acceptable limits.
4). Manageability — is the solution manageable, and how would it be managed.
5). Cost — what are the costs for the solution, are they acceptable.
6). Risk — what are the risks associated with the solution. Is the level of risk acceptable to the enterprise?
2). Availability — what availability is required for the application system, and does the solution provide it. Reliability, Robustness part of Availability Sensitivity, depending on how you mean this, it is an aspect of Availability, Performance
3). Scalability — What is the scalability of the solution, is it within acceptable limits.
4). Manageability — is the solution manageable, and how would it be managed.
5). Cost — what are the costs for the solution, are they acceptable.
6). Risk — what are the risks associated with the solution. Is the level of risk acceptable to the enterprise?
But what about all the other factors? Such as Reliability, Robustness, Sensitivity, Comprehensiveness, Speed, Responsiveness., etc. Clarify the comprehensiveness from every aspect, Simplicity is one of the key plates to balance in addition to Cost, Risk, and Quality defined by architecture. Indeed, the art of simplicity is the puzzle of complexity.
3. A Flexible Way –Even Adding the Essential Complexity
How do you know that Simplicity is "just right"? How do you know you have the minimum required complexity, to support flexibility without hurting the support/maintenance costs? Or, we could also talk about complexity as either "essential complexity" (the complexity required to provide bare minimum functionality that is necessary to meet the needs) or "accidental complexity".(which is everything else - almost). To achieve simplicity you would have to address the complexities of the subject matter.
- Things that are simple tend to be inherently less flexible: Making things "flexible" is usually regarded as adding some complexity in order to create flexibility. It typically requires anticipating a need and putting something in place to handle it. It is possible for an object to be simple and complex, common and different at the same time. It is a question of the perspective of the semantic and the relationship and levels of consciousness.
- Simplicity is the design of looking for what is common for maximum reuse: Simplicity is the building block. Complexity is the content put in the building blocks and the outcomes from interactions with the building blocks, theoretically because of recursion can tend to infinity. While flexibility is often contrasted with "adaptability" -- the ability easily and quickly change (adapt) according to circumstances without necessarily anticipating them or adding anything explicitly for that circumstance.
- With simplicity, it does not explicitly mean adding flexibility: Although removing inessential complexity and assumptions/dependencies does make it easier to adapt/evolve later if only by having less "stuff" in the way that is impacted by a future change. Simplicity does not mean that it is rigidly hardcoded and tightly coupled. Simplicity implies in EA ease of change. Simplicity in EA is the ability to handle any change or exception in your stride, without breaking a sweat; it is not a simple rigid approximation of what everyone does on railway tracks that you cannot diverge from. That is approximation being incorrectly labeled simplicity.
- "Simplicity" in the EA project should be measured: With flexibility, comes complexity, but an architecture that minimizes the impacts of change greatly simplifies future evolution. Abstracting changing aspects, while potentially complex to implement, will ultimately result in simplicity. The challenge is to avoid “future-proofing” and attempting to abstract every conceivable change. Business alignment and clear strategic objectives will help determine the appropriate dynamic aspects and enable the architect to simplify those elements appropriately.
0 comments:
Post a Comment