Image via Wikipedia
This is the 3rd post in this series Architecture – Understanding The Criteria.
Here we will look at the following aspects of an enterprise architecture:
Interoperability, Configurability,Portability, Resilience and Fault-Tolerance.
Wikipedia defines interoperability or interoperable as a property referring to the ability of diverse systems and organizations to work together (inter-operate). When we talk about software and interoperability, what we refer to is the ability of different systems to talk to or communicate with each other , in a meaningful manner, thus allowing businesses to unlock value from their existing systems. Interoperability could be within the enterprise allowing departmental systems to integrate their processes or it could be collaboration with their suppliers and/or customers systems, thus integrating the information systems in the extended supply chain.
You can read more about achieving software interoperability here.
Configurability or configurable systems:
Is your system configurable? Can it be configured to meet my specific requirements? That is the question from the customer. What do you answer?
Most modern systems are configurable. That is, you can either turn on or turn off certain features of the software system using parameter values that are either stored in a system file or a database. The configuration features are usually accessible to the system administrator or a manager role in an enterprise system.[ Before you get too confused, for the layperson, the simplest configurable system that you should think of is a software program that you install on your machine. The program might be a shareware program that has some limited features; after purchasing the system for a small fee, you can unlock all its features by keying in or cutting and pasting the license key.]
For more savvy users, especially those who are more familiar with web browsers, the ability to configure your privacy levels for browsing habits, is another example of a configurable software system.
This is extended to large enterprise solutions, built using decoupled modules. The modularity allows certain modules to be turned on or off depending on what the user requirements are. Configurable systems are more prevalent in packaged software systems, but any good software architect/engineer worth his salt, will include these practices while building custom-built software as well.
Configurable systems are not limited to the domain of software systems. When you buy a car or a computer, there too you specify the specific configuration or requirements you have in mind, as per your needs and/or as per what you can afford.
Configurability , like portability, provides flexibility.
Portability is the art of writing software so that it can run on different operating systems and/or hardware architecture.
Most technical personnel understand portability in terms of porting an application to a different operating system and/or system architecture. This is a task to be performed by versatile programmers who are familiar with the architecture being ported from and the architecture being ported to. There are many reasons why this should happen; one of the principal causes is the upgrading of the hardware the software is being run on; another reason could be migration from one operating system to the other but the enterprise would like to retain the applications in its IT portfolio, if possible.
Web applications and Java technology applications avoid this dilemma ( and now .NET) because in the case of web applications, all you need is a browser; the operating system you are running the system on is irrelevant. As for Java and .NET, as long as the operating system you are running the system on has a JVM or CLR, your system should be able to function w/o any modifications.
More about data portability here.
The dictionary defines resilience as the power or ability to return to the original form, position, etc., after being bent, compressed, or stretched; elasticity or the ability to recover readily from illness, depression, adversity, or the like; buoyancy.
When we talk about resilient systems, what we refer to is the ability of software systems to recover gracefully or degrade gracefully w/o sudden loss of functionality. Resilient software systems is by itself a generic term. This includes the ability to be fault-tolerant and reliable. In today’s world, an enterprise is only as resilient as its IT systems. This especially holds true for financial institutions where IT forms the backbone of their daily business use and transactions.
When we refer to fault-tolerance, we are referring to software systems that are able to degrade gracefully. At no point, are we referring to people though there is definitely scope for fault-tolerance in human beings as well, especially project managers!
The ability to recover from errors and continue functioning, albeit at a decreased level of functionality or performance level characterizes a fault-tolerant system. Fault-tolerant systems originated with software written for the NASA space program, where it was critical that software should continue to function even if a critical error occurred.
Fault-tolerant systems strive to catch errors where they occur but like human beings, fault-tolerant systems may not be infallible, and thus a certain amount of redundancy may be built to help cope with unanticipated failure.
The basic characteristics of fault tolerance require:
- No single point of failure
- No single point of repair
- Fault isolation to the failing component
- Fault containment to prevent propagation of the failure
- Availability of reversion modes
Anticipating for failure is key to building a good fault-tolerant system. In this case, failure is truly an option and providing for it is key to building a fault-tolerant architecture.
Other key features of fault-tolerant systems is replication and modularity. The separation of concerns helps to simplify system design and decouple and localize system failures.
To be continued….
Have a great day!
|Share this post :|