The Part 2 architecture (P2A) is your proposed conceptual model of the objects, relationships, and processes that provide the solution. In Part 3, you are asked to review aspects of your P2A and explain and justify your design process. For example, you need to explain how your P2A identified and eliminated inefficiencies, such as superfluous steps in a process. During your P2A design, development, and representation of the architectural idea/solution, you hopefully will have developed documentation and an explanation of the relationship between the design process and the architectural outcome. This will enable you to successfully describe the orchestration of the various design instruments (for example, UML) and to communicate your architectural concept and its resolution during the allotted time. That said, this appendix presents some essay answer examples to general/typical questions posed in Part 3 and some tips on preparation.
You will be asked to appear at the testing center and in 120 minutes (two hours) provide your reasoning for all the choices made in Part 2. That said, you will have hopefully documented Part 2 architecture choices and their justification. In the real world of enterprise computing, decisions concerning architecture and infrastructure are formalized and include a compare/contrast survey of the alternatives. For the essay exam, you should take the time to formally answer the questions posed in this appendix. This will force you to review your application and to draft answers to typical questions included herein.
As mentioned, Part 3 is a set of essay questions related to your project. Exam Parts 2 and 3 should be done within six months after the assignment is downloaded. The essays we include in the chapters of this book should help you with this part. Eight essay questions appear in Part 3, and you get 120 minutes to complete them. As you saw in Appendix A, the Part 2 sample assignment requires that you architect a solution for a bank securities trading system. You will be graded on correctly solving the technical and performance requirements.
In Appendix A, we presented you with a securities trading solution. Most systems in the real world start off and perhaps end with architecture review and justification, which is what we will do in this appendix. You explain why your architecture is the best choice considering all the alternatives. The particular case study application in Appendix A was developed for a Wall Street clearing firm that interacted with hundreds of correspondent trade brokers and their customers. It was designed to help the firm by facilitating the customers’ ability to trade securities on the Web. Typical Part 3 essay questions are:
How does your design handle availability? How does your application interact and communicate with external systems and applications?
Because the questions are somewhat predictable, you should prepare and write some of them out as preparation. That said, let’s begin.
The Case Study Infrastructure
Bank of New Amsterdam (BNA) has several different operating systems running many kinds of software systems. The primary platform for the production business data is the mainframe. In addition, peripheral Microsoft and Unix boxes provide Internet services and other software to provide reporting capabilities, using a SQL-based DBMS shadow copy of the business data. BNA also has an investment in SQL-based DBMS (for example, Oracle on the S/390). Several preexisting legacy applications provide trade-processing links to the major securities exchanges. These applications work well and have been developed and maintained for the past two decades, during which time a great deal of time and money has been spent to maintain them. The applications do not need modification; instead, they are constantly “facaded” using a browser/web front end to service the growing base of mobile devices.
The advantages of using the mainframe include its reliability, scalability, flexibility, and security. The mainframe has been running continuously for years in BNA without major problems. The mainframe can easily be amended to add hardware resources, such as CPU, memory, disk, and networking hardware, to increase capacity without changing the operating system or application systems. In addition, the CPU, memory, and disk space can be redistributed as application requirements change.
Java Database Connectivity (JDBC) connection pooling and Java’s platform independence provide the performance and scalability needed. Because budget is a limiting factor in an economic downturn, where every developer is competing for business, it is critical that you deliver a solution quickly that will integrate with the organization’s existing infrastructure. The clustered HTTP server, clustered application servers, and SQL-based enterprise relational database management system (RDBMS) are all in existence on the company’s legacy IBM mainframe enterprise servers. The enterprise servers are clustered for failover and load balancing. They can handle JSF, JSPs, and servlets, they run SOAP and REST services as well as EJBs, and they provide JDBC connection pools and caching to access and update user data.
Application Servers
The application servers are also connected via TCP/IP sockets to the bank’s mainframe set (BNACS API). This API is used to communicate with and retrieve information from the mainframe system via an XML/JSON-based message format. Finally, the JEE application server is connected to the bank’s CTPS (the continuous trade-processing system) application. The JEE application server’s application sends and maintains orders, and it can look up order status by communicating with CTPS via an XML/JSON message format.
Continuous Trade Processing
The CTPS system is an order-routing system that is connected to several exchanges and market makers (firms that stand ready to buy and sell a particular stock on a regular and continuous basis at a publicly quoted price). The system receives orders either by direct entry into its terminals or via an in-house-built interface. These orders are routed to the appropriate exchange or market maker according to a set of correspondent-defined rules. Executions are then passed back from the exchange or market maker to CTPS, which updates the order file and forwards the result of the execution to the mainframe.
SQLBIS Database Server
The SQLBIS database server was created to service BNA’s trading website, Brokerage Information System (BIS). On the database server are several databases (or data marts) that are used by BIS and the BIS Trading Area to look up account and application access as well as cross-references and other information. The ORDERDB database was created exclusively to support the JEE application server’s applications. In development, the tables and views were created by developers and migrated to production by the database administration (DBA) group.
Essay Questions and Sample Answers
As the exam site puts it, “This is another stimulating test to verify your architectural knowledge about design decisions.” As you know by now, architectures can be implemented in many ways, with different design decisions. The questions on the exam will ask why you have chosen a certain way and why not another way. You need to answer such questions with a focused explanation. To that end, this section presents some typical questions and answers for Part 3.
How Does Your Design Handle Availability?
The availability of a system is the degree to which a system, subsystem, or equipment is operable and in a committable state. The conditions determining operability must be specified. Availability is the ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval.
Because our trading application has users in every part of the globe, our required availability is virtually 168/168—that is, the application must be available for all 168 hours in a week, with the exception of holidays and some softer parts of the trading week (for example, weekends). Our availability objective, specified in decimal fractions, is 0.9998. To accomplish this, we employ the use of application server clustering for load balancing and failover. We keep our front-end UI components as stateless as possible by using granular services. Our enterprise mainframe is always online because it is the “books and records” of the firm, and today’s risk compliance law mandates that it is constantly checking its pulse and responding to issues immediately. Additionally, we set up our trading application such that it always accepts orders, placing them in a message queue. We use our back-end application servers to handle the queued requests (“make a trade” and “get a price”), allowing us to spot and respond to spikes and add queue handlers as necessary—essentially providing redundancy and failover. Moreover, we review and audit all activity and monitor component thresholds to avoid failures.
How Does Your Design Handle Reliability?
Reliability is the ability of an item to perform a required function under stated conditions for a specified period of time. Reliability is also the probability that a functional unit will perform its required function for a specified interval under stated conditions. For example, in the trading application, the reliability of the “BUY” or “SELL” transaction is critical to the operation of the system. An outage transaction, for example, can effectively shut down the business. For users requesting a trade in markets that are not yet open, we can make the outage invisible to user: “I’ll take your order and inform if there’s a problem.”
In the arena of Internet trading and ubiquitous computing, the consumer cannot be placed in the position of troubleshooting the computer system. Reliability is critical because, eventually, users expect the trading system to work just as well as any other appliance in their life—and even better. Our clustered solution provides load balancing and is capable of routing all traffic to a “round-robin” stack of servers; therefore, if any server is inoperable, it is removed from the stack.
The steps taken to promote availability also contribute to the reliability of the system. In a typical HA cluster, instances of an application run simultaneously on application servers in the cluster. Each has its own Java Virtual Machine. Because each server has its own JVM, if you update data in a local cache, the effects of the update will only be seen by that JVM. For that reason we employ a real-time distributed cache to keep data synchronized across the JVMs. To facilitate the stateless HTTP protocol, our application uses the HTTP session to store session information. In our clustered environment, we replicate session data in real time. This is done by saving the session data in a database and then enabling replication at the database level.
How Does Your Design Handle Scalability?
Scalability is the ability to support the required trading system availability and performance as the transactional load increases. In our trading system, we can respond and make transaction performance increases using “vertical scalability.” For this we can add capacity (memory and CPUs) to existing servers. We can also respond and make transaction availability increases via “horizontal scalability” by adding servers. In terms of scalability, our trading system can scale to accommodate more users and higher transaction volumes in several different ways:
We can upgrade the hardware platform. Our use of JEE servers is a solution that offers platform independence and enables rapid deployment and easier integration of new technology.
We can improve the efficiency of communications. In a distributed environment, the communications overhead is often a performance bottleneck. We add session management to improve communication among clients and servers through session pooling.
Our use of clustering provides transparent access to multiple servers to increase throughput during peak loads. The load balancing provided by clustering is necessary to support the unpredictable and uncontrollable demands of trading applications.
We can improve communication between the application component server and various data sources through the use of connection pooling management.
Scalability is more a system problem than a CPU architecture problem. For this reason, we capture trading system metrics, for example, to measure the number of users in a 24-hour period, response time, as well as average and longest running transactions. These metrics provide answers so that we can include the following:
Graceful degradation, all the way up to 100 percent system load
The ability to add capacity incrementally (CPUs, memory, I/O, and/or disk storage) without disrupting system operation
The ability to prioritize the workload so that unneeded work can be suspended at times of peak activity
We also employ techniques such as logical partitioning to shift system resources. Portions of the system resources can be assigned to the partitions, with the assignments enforced by the hardware. This allows resources to be shifted from development to production, or between different systems involved in production, by simply shifting the percentages assigned to the partitions. Capacity is affected by scalability—for example, one machine handles 500 transactions or five machines handle 100 transactions each.
How Does Your Design Handle Performance?
Performance is defined as the amount of work accomplished by an application as compared to the time and resources used. In the context of a web-based application, good performance involves short response time for a trading transaction, as well as high throughput and high availability of the application. Therefore, in a trading application, response time and response ratio are important to the success of the application. With Michael Lewis’s “Flash Boys” as competition, large institutional users want “up to nanosecond” pricing information. When a trade is entered, the users want immediate execution and confirmation as well as the accurate price paid or received. The key in establishing good performance is to identify and control expensive transactions. The architect should state target performance criteria before implementing within a production environment. For example, the first visible response in an Internet securities trading application’s browser view, when the application is under maximum specified load, must occur in less than three seconds, 95 percent of the time. Measurement is made at the enterprise’s external firewall.
In the trading system, when measuring performance, the architect must consider and attempt to quantify the cost of an operation (data or computational), which can involve “round trips” across our application cluster of servers and across our network connections—before finally returning a response view to the user requestor. We include tables to capture system metrics, which are used to determine the real cost of each transaction. After analysis, we could improve performance by amending software to execute functions fast enough to meet goals. Response time (the time it takes to respond) and response ratio (the time it takes to perform the function) are important to a securities-trading application. Both figures should be as low as possible, but a ratio of 1 is the target. For example, suppose a user requests functionality requiring a great deal of processing or database searching, and it takes a minute to process. The user will not see a result for a minute—seemingly a long time to wait. However, if the result can be viewed in one minute plus 20 seconds (a response ratio of 1.3333), that is still good performance. Alternatively, suppose that the processing takes only 1 second, but the user does not see the result for 20 seconds (response ratio of 20); that is not good performance.
To start, we analyze the client environments and ensure that the proposed solutions will not only meet the business needs but ensure a reliable production IT environment. Before we went operational, we piloted the system to weed out performance problems that could disrupt our client business (securities trading) and result in loss of revenue. Our performance handling involved a number of accepted performance enhancement techniques. We set up a cluster of application servers (for example, WebSphere Process Server and Tomcat) that use a round-robin handling to ensure that we maintain our stated performance goals. We put in place metrics collection and analytics to measure response time. We responded by adding database performance enhancements such as indices and caching to speed up lookups and update processing. We used metrics to identify hot spots and used maintenance programs to clean and refresh components and their supporting data. See the answer for “How Does Your Design Handle Scalability,” which allowed us to respond to performance issues quickly and without interruption to business.
How Does Your Design Handle Security?
Our goal for security is to protect resources and assets from loss. Resources include most importantly the integrity of the trade data, which directly affects the business, as well as other information, services, and equipment such as servers and networking components. Our security is controlled access to component services and protection such that data is appropriately managed. The security for the integrated network, Internet, server, and securities-trading application is controlled by one administrative tool, which is a manageable solution and what we aimed for. This approach provides Single Sign-On (SSO) to our rich infrastructure of network and system services. Obviously, firewalls and authentication mechanisms are also used to support Internet security. With enterprise-wide control, multiuser access is managed without requiring explicit securities-trading application code. We created software APIs to each environment’s ACL to facilitate SSO and other security measures.
We not only have to ensure that trade data is accurate, but we have legal obligations with respect to Gramm–Leach–Bliley legislation covering financial data. Therefore, the security we put in place had to accomplish the following objectives:
Privacy Preventing information disclosure to unauthorized persons
Integrity Preventing corruption or modification of resources
Authenticity Proof that a person has been correctly identified or that a message is received as transmitted
Availability Assurance that information, services, and equipment are working and available for use
We broke out the risk based on a set of threats. These threats include accidental threats, intentional threats, passive threats (those that do not change the state of the system but may include loss of confidentiality but not of integrity or availability), and active threats (those that change the state of the system, including changes to data and to software).
We established a security policy (that is, a enterprise trading statement) defining the rules that regulate how we will provide security, handle intrusions, and recover from damage caused by security breaches. Based on our risk analysis and cost considerations, we engaged the users so they could understand these rules and agree to abide by them. Our objectives are facilitated in some ways by the enterprise, including firm-wide security services provided for implementing the security policy of an application (for example, the trading application). A standard set of such services includes the following:
Identification and authentication Unique identification and verification of trading system users via certification servers and global authentication services (Single Sign-On services)
Access control and authorization Rights and permissions that control what resources trading system users may access
Accountability and auditing Services for logging activities on network systems and linking them to specific user accounts or sources of attacks
Data confidentiality Services to prevent unauthorized data disclosure
Data integrity and recovery Methods for protecting resources against corruption and unauthorized modification—for example, mechanisms using checksums and encryption technologies
Data exchange Services that secure data transmissions over communication channels
Object reuse Services that provide multiple users secure access to individual resources
Non-repudiation of origin and delivery Services to protect against attempts by the sender to falsely deny sending the data, or subsequent attempts by the recipient to falsely deny receiving the data
Reliability Methods for ensuring that systems and resources are available and protected against failure
Our enterprise infrastructure uses many diverse user authentication and authorization (Auth/Auth) credentials and access control lists. For the most part, Auth/Auth details and values are stored in the enterprise LDAP database. Spring’s JAAS (Java Authentication and Authorization Service) is used to control the authentication and authorization in the application. Spring is configured to connect to the enterprise LDAP. Front-end access to each UI component (for example, Java Server Page) is controlled by a taglib (for example, Spring-Security). Once the user submits the form with a username/password, the application checks the details with LDAP. As mentioned previously, security is controlled by a firm-wide administration tool.
How Does Your Design Handle Extensibility?
Extensibility is the ability to extend a system vertically or horizontally with relative ease. This is achieved by loosely coupled interfaces and encapsulation. We use SOAP/REST services for most UI interfaces. The services communicate via extensible XML/JSON message formats. This ensures that functional requirements have limited impact on the application. It is critical in a trading system to be able to extend functionality. Extensibility requires careful modeling of the business domain to add new features based on a model. The securities-trading application is designed with separation of concerns: presentation tier, business tier, persistence tier, and integration tier. Each layer is loosely coupled with each other with good usage of design patterns, interfaces, and best practices of object-oriented design such as encapsulation and inheritance. Therefore, any change to subsystems will have less impact on systems that are using the subsystem as long the interfaces remain same. Even if there are changes, the impact will be minimal for adapting new changes. We have made use of granular services to handle the components of each transaction. The use of business domain controllers to assemble and invoke distinct services to create transactions makes our design extensible.
How Does Your Design Handle Maintainability?
Maintainability and adaptability of software are important to keep software running for a long time. Where possible, we have made use of object-oriented designs to be more flexible and adaptable than the older procedural designs, thus reducing maintenance costs. We make use of OO principles to reduce maintenance costs in the following way: we use object–oriented modeled business entities and processes to address the “separation of concerns.” Thus, we are able to adapt to new functional requirements because the interface typically is not affected. Our object-oriented designs are easier to change in response to new trading business requirements. Our object-oriented design is focused on identifying stable business objects that can be made to interact in new ways (for example, “get a price” and “make a trade”).
Because we are part of a large investment banking infrastructure, we make use of the established layers. We monitor the communication between two layers to determine how the securities-trading application can be partitioned at that point for physical distribution across tiers. In our case, layers represent component relationships in the service implementation. They are the application, virtual platform, securities-trading application infrastructure, enterprise services, and compute and storage layers, as detailed here:
Application The securities-trading application layer is the user and business functionality of a system (for example, the .war or .ear files deployed on the application).
Virtual platform (component APIs) The virtual platform layer contains interfaces to the securities trading application infrastructure component APIs (for example, REST Web Services and the servlets to “get a price” or “make a trade”).
Application infrastructure (containers) The application infrastructure layer contains products (for example, JBOSS and IBM’s WebSphere) that provide for the operation and development of the application. The virtual platform components are housed in an application infrastructure container.
Enterprise services (OS and virtualization) The enterprise services layer is composed of the operating system (for example, Linux) and software (for example, Oracle DBMS) that run on top of the compute and storage layer. This layer provides the interfaces to operating system and storage functions needed by the application infrastructure layer.
Compute and storage The compute and storage layer consists of the physical hardware used in the enterprise architecture.
Due to the layered (loosely coupled) architecture, each layer addresses a particular need so that any enhancement to the trading application can be made easily. Also, each layer is loosely coupled with best design practices, which makes understanding, analyzing, and debugging the trading functionality as well as making changes easier.
How Does Your Design Handle Manageability?
With respect to the trading application, the ability to administer and manage the system resources to ensure the availability and performance of all system components is how we provide manageability of the trading application with respect to the other capabilities. Manageability refers to the set of services that ensures the continued integrity (or correctness) of the component application. It includes security, concurrency control, and server management. A metric example of manageability would be the number of staff hours per month required to perform normal upgrades. The trading application is one of many that is managed by BNA. That said, we have made use of their wide array of tools to ensure availability and performance of all system components and to alert all parties when system components are affected and unavailable for whatever reason.
How Does Your Design Handle Persistence?
Our trading application data is primarily stored on Unix-based Oracle servers. In front of the database are services that provide an API that insulates the developer from needing Hibernate/iBatis knowledge and avoids a tight coupling between frameworks and code. We have developed Spring-based services that manage sessions, access the data, and cache frequently used reference and other data to provide performance and integrity.
How Does Your Design Handle the Presentation Tier?
REST stateless services provide easy development for distributed applications. They also provide system-level services that free the developer to solve business problems. These services allow for scalability in distributed systems and facilitate transactions that ensure data integrity.
Because we use services to provide the majority of business rules, our front end can be varied. We use a combination of Java Server Faces (JSF), which provide rich JavaScript functionality but require skill to build efficient/performant UI pages. We also use Java Server Pages (JSP) with an MVC framework (for example, Spring MVC or Struts).
Before the Exam: Prepare and Practice
Writing a good essay requires synthesis of material that cannot be done in the minutes you have during the exam. In the days before the exam, you should:
Anticipate test questions. Look at the questions from the online forums. Did you have to compare/contrast alternative approaches?
Practice writing. You may decide to write a summary of each prototype question you have been discussing, or a short description of the application solution you’ve created for Part 2. Focus on clarity, conciseness, and understanding the differences between the nonfunctional requirements of an architecture.
Memorize key facts and names. You will have to support your argument with evidence, and this may involve memorizing some key events, the names of theorists, and so on.
Organize your ideas. Knowledge of the subject matter is only part of the preparation process. You need to spend some time thinking about how to organize your ideas. Let’s say a question asks you to compare and contrast how you provide manageability for your application. The key components of an answer to this question must include the following:
A definition of the alternative approaches
A brief description of the issue
A comparison of the two alternative approaches
A clear and logical contrasting of the alternative approach (noting how and why they are different)
How to Proceed at the Exam
Many students start writing too soon after scanning the essay question. Do not do this! Instead, try the following:
Perform a “memory dump.” Write down all the information you had to memorize for the exam in note form.
Read the questions and instructions carefully. Read over all the questions on the exam. If you simply answer each question as you encounter it, you may give certain information or evidence to one question that is more suitable for another. Be sure to identify all parts of the question.
Formulate a thesis that answers the question. You can use the wording from the question. There is not time for an elaborate introduction, but be sure to introduce the topic, your argument, and how you will support your thesis (do this in your first paragraph).
Organize your supporting points. Before you proceed with the body of the essay, write an outline that summarizes your main supporting points. Check to make sure you are answering all parts of the question. Coherent organization is one of the most important characteristics of a good essay.
Make a persuasive argument. Most essays ask you to make some kind of argument. Although there are no right answers, there are more and less persuasive answers. What makes an argument persuasive?
A clear point that is being argued (a solid approach to the issue)
Sufficient evidence to support that approach
A logical progression of ideas throughout the essay
Review your essay. Take a few minutes to reread your essay. Correct grammatical mistakes and check to see that you have answered all parts of each question.
Best of luck!
CERTIFICATION SUMMARY
This review of how to approach the essays after completion of the Part 2 case study provides some examples. As an architect, and for the purposes of the essay assignment, you should always document the reasoning behind the analysis and design decisions made during a development project. These documents will provide a clear picture of the enterprise application and the reasoning behind its infrastructure, functionality, and deployment particulars. It will also help in evaluating and extending and amending the application when the inevitable change occurs.
