Back Up Next

Chapter 6: Designing Component Solutions Overview

Certification Objectives. 1

Identifying Business Environment and Information Technology Challenges. 3

Exercise 6-1: Designing Solutions. 4

Answers to Exercise 6-1. 5

Achieving Good Design with MSF. 5

From the Classroom.. 9

Interim Milestones. 11

How Milestones in the Process Model Map to Team Roles. 13

Scheduling. 14

Modular Design and the Solutions Design Model 21

Enterprise Architecture. 25

Exercise 6-2: Determining the Appropriate MSF Design Phase. 32

Answers to Exercise 6-2. 32

Certification Summary. 33

Two-Minute Drill 34

 

Certification Objectives

·       Identifying Business Environment and Information Technology Challenges

·       Identifying Typical Problems That Lead to Design Flaws/Failure

·       Success in Software Design

·       Achieving Good Design with MSF

·       Microsoft's Process for Designing Solutions

·       How Solution Design Relates to Enterprise Architecture

In this chapter, we’ll discuss some of the problems commonly encountered in designing an application. This includes some of the challenges currently encountered in Information Technology, as well as a discussion on the ten common problems that lead to design failure and flaws.

Also in this chapter, we’ll discuss the models and issues dealing with the design of component solutions. We’ll see how MSF provides proven methods for designing applications and solutions that use components. In reading this chapter, it’s important to realize that not everything is covered here. This information introduces you to some of the models, principles, and practices of designing these solutions, which we’ll expand on in later chapters.

Success in Software Design

Designing software can be a bittersweet experience at best. While it’s exhilarating to reach a major milestone in a project, and to see a product you toiled over being welcomed by users, the problems of reaching these points can feel overwhelming. Meetings, schedules, budgets, placing people in team roles, and so many other tasks need to be done before the first line of code is even written. If you're using outdated and obsolete models that worked well a decade ago but don’t address issues faced today, you may be frustrated by the time that first line is written.

If you’ve used computers for awhile, you’ve probably come across a few different applications that failed to provide the benefits they promised, and perhaps a few that barely worked at all. It’s important to remember that most problems with software development products aren’t the result of bad coding, but bad design. Any programming code that a developer writes is based on information obtained during the design process. If the design is bad from the start, no amount of programming talent will be able to save the project.

Being successful in software design isn’t as elusive as it may seem. One of the easiest ways to deal with design problems is to understand the obstacles others have encountered, and learn how to overcome or avoid them. As we’ll see later in this chapter, there are a number of common problems that can lead to design flaws and failure. By discussing issues with people who have designed similar projects, you can often identify difficulties before they become major problems.

The importance of applying good models to a project can’t be stressed enough. Software design and development is complex, and as we’ve seen in the previous chapters, models help to break down this complexity into manageable parts. While there are many models and methods available to you, it’s important that the models you choose work well together. Otherwise, you could have one model that works well on its own, but jeopardizes the benefits of other models used in your project. By using models that work well together, and have proven their worth in real-world projects, you can minimize the possibility of failure in your project.

Identifying Business Environment and Information Technology Challenges

Anyone who’s been in Information Technology for awhile can tell you that one of the biggest challenges are those faced by the business environment itself. Issues such as global competition and the need for new services and technologies to enhance the performance of workers have changed and continue to change the face of business. As the business environment changes, IT must try to keep up with the changing policies, security requirements, and other influences that influence the development of software products. To add to these challenges, it can be difficult trying to get the necessary information to develop a solution, because customers and users may not be able to communicate what they really want.

Unfortunately, as your team attempts to face these challenges, they may be hindered by a number of problems. Current methodologies used by the team may not allow additional user requirements to be added mid-stream. Members of the team may not fully understand what’s required from a project, and even if they do, they may find their role in the project’s success unclear. Schedules may be so demanding that they jeopardizing the product’s release date. Projects may be too big and complex, and there is a need to break these large projects into manageable parts. The design may be so flawed that it does little to enhance work performance, and actually slows it. Each of these is an important issue, and if the solution you’re developing is hindered by these issues, it can affect how an organization is able to do business.

There is a symbiotic relationship between an organization and its IT department, neither can get along without the other. Because of this, it is important for Information Technology to use the proven methods to ensure their software development projects are successful. There is no time in IT to experiment with models, principles, and practices that may or may not work.

Exercise 6-1 tests your comfort level with designing solutions and the MSF model. See how you do and then read the rest of the chapter.

Exercise 6-1: Designing Solutions

Please indicate with a “T” or an “F” whether these statements are True or False.

1.     You can use the same software models from 20 years ago for today’s application designs.     _____

2.     Because the business environment continually changes, Information Technology must attempt to keep up with changing policies, security requirements, and other issues that change the way the organization does business.     _____

3.     Information Technology must use proven development and management methods to ensure projects are successful.     _____

4.     The MSF is a static methodology that clearly delineates what steps to take in the development process.     _____

5.     You may use mature analysis and design techniques with the MSF model.     _____

6.     Incremental internal release of a software product means a new version with added functionality is put into production.     _____

7.     Product management is responsible for estimating the development schedule and getting it approved.     _____

8.     Tradeoffs may be made between schedule features and resources.     _____

9.     Large projects should always be developed as a monolithic application to avoid losing functionality.     _____

10.  Daily builds may, in reality, be accomplished once a week.     _____

Answers to Exercise 6-1

1.     False

2.     True

3.     True

4.     False

5.     True

6.     False

7.     False

8.     True

9.     False

10.  False

Achieving Good Design with MSF

The models in the Microsoft Solution Framework provide you with the ability to address many of the challenges and difficulties faced by solution developers. It takes the best practices and principles used by companies like Microsoft, and puts them in a format that can be applied to any project you encounter. By being proven, you don’t need to worry about having to test these models for effectiveness, and worry about the first projects you use them on failing.

Rather than being a static methodology, MSF is a framework of models that can be adapted and applied to an organization’s specific needs. In fact, you can continue using the analysis methods, data modeling, and user interview techniques you’re comfortable with, providing they can be adapted to evolving technologies. Each model in the framework is a flexible component, so you can adapt and combine the different MSF models with the methods and techniques your organization currently uses.

Identifying Typical Problems That Lead to Design Flaws/Failure

Many of the problems and dissatisfaction customers have with software are the result of design problems. While the lines of code work, and the product functions as it should, mistakes in the design phase caused the project to be less than successful or to fail dismally. Like other areas of solution development, there are common problems that you can watch out for, and thereby avoid flaws and failure resulting from design. In this section, we’ll cover ten of the common issues that lead to problems in design.

Of all the possible problems you can encounter in designing an application, the most common one you’ll experience is the design failing to deliver what the customer expected. Often, this is a result of the customer not knowing what they really wanted. This may seem strange at face value, until you realize that people often find it easier to say what they don’t want, rather than what they do want. Because of this, it is important for the designer and customer to sit down and come to a clear understanding of what needs to be included in the product. This is the purpose of a specification. You’ll remember from Chapter 4 that the functional specification is the result of the project plan approved milestone, and contains information on what needs to be done to create the product. Creating a specification requires a clear understanding of the project’s end result, and the specific items to be included in the product. Once created, this information is used throughout the development process to create what customers and users expect.

The second most typical problem in design is using inappropriate technologies to complete the project. As you know from your own experience, developers and analysts learn and become experts in specific programming languages, DBMS (database management systems), and other technologies. Therefore, when they design an application, they use the tools they are most familiar with. Unfortunately, the technologies they incorporate in a product may not be the best ones to use. It’s important to evaluate different technologies available, and determine which is best suited for your project and how it should be utilized.

The third most common problem in design is scalability. This deals with the number of people who will use your product. It’s important to remember that just because your product works well with ten users, it may not work well with hundreds or thousands of users. Remember that each user added to a network’s population eats up more resources. While your application may work well on a test network of a dozen or so people, its usability may crumble if it is not designed to deal with a significantly larger user base.

A software product’s ability or inability to deal with errors and other unexpected occurrences is the fourth typical problem in design. Applications should have code added to deal with any errors that might occur, or messages sent to the application from the operating system or any servers the application accesses. When your software product needs to access resources, you should have error handling code to deal with the possibility that the resource may not be there. Error handling means having code (called error handlers) added to your program’s code to deal with problems as they occur. For example, let’s say your application needed to access a specific database, but the database had been moved to another location or accidentally deleted. Such error handlers would deal with this problem, and provide another course of action. Because of the importance of such code, you should add error and message handling code from beginning to end of your software product’s development.

Fifth in our listing are the problems involved from integrating business rules into a single application. Business rules are rules on how data is utilized and manipulated, which adhere to the enterprise’s way of doing business. Business rules reside in the business services tier, where the combination of such things as validation edits, logon verifications, database lookups, policies, and algorithmic transformations constitute the enterprise’s way of doing business. Considering that over 80 percent of applications running on a Windows platform access data in some way, this is a significant issue for your software design. If business rules are integrated into applications and those rules change, you and your development team will need to change the code in every application. Because of this, you should put business rules in a central repository or server, so they can be accessed as needed. You can also avoid this problem by integrating business rules into COM components, which are then accessed by applications that utilize the rules. When a business rule changes, you modify the code in the COM component rather than in each application that uses the rule to access data.

Just as accessing data is vital, it’s equally important that users are able to update records without a problem. Unfortunately, it’s difficult to know how many of your product’s users will be updating the same record at the same time. The sixth most common problem in design is concurrency, which is the designer’s failure to account for numerous users updating the same records. When numerous users do heavy updates and inserts on frequently used pages of a database that contain the most current row, it can seriously bog down a system. In any database you design, you should take into account the maximum number of users who will concurrently use the database. If you are creating an updated version of an application that uses a database, analyze the current number of concurrent users. If it is a new design, try to determine the worst-case scenario of users who will concurrently use records in the database; then apply it to the design. Chances are, unless you’re designing a desktop application used by a single user, more than one user will be accessing the same records simultaneously.

The seventh typical problem in design is security. This is a particularly important issue in software development, as the last thing you want is an unintentional intruder or malicious hacker getting into areas where they don’t belong. Imagine a person who’s getting fired reading about it through a supposedly secure database, or a hacker deleting and changing records. A number of problems could result from insecure access to data. When creating applications that access data, you should build stored procedures or server-side COM components that can control access to the data. As mentioned earlier, the use of COM components also allows you to integrate business rules on a server. By incorporating security into server-side components, you can change and enhance security procedures without having to recompile and reinstall applications on each of the workstations in your network.

Eighth in our listing of typical mistakes is adding BLOBs to databases. If you’re a fan of B-movies from the 1950s, this comment has probably put some strange images in your head. A BLOB is an acronym for Binary Large Objects, and includes such things as graphics, compiled code, tomes, and sound, which can cause serious performance issues. By including a data column containing such binary data, you can slow down the speed that data is accessed. Imagine a database of employees that includes an employee’s photo with each record. Not only does the photo enlarge the size of your database, but it slows performance as users access each record. It is far better to leave the binary data in its original source file, and add a pointer from the database to that file. Views or SELECT statements can also be used to return only the data desired from a given table. You can also add a command button to your user interface that accesses the data on demand. This allows you to expand the amount of data shown, rather than displaying it automatically each time the record is accessed.

The ninth most typical problem deals with buying third-party solutions. The Not Invented Here (NIH) syndrome is based on ego, with a prevalent feeling that software products developed outside the organization should rarely be used. Considering that there are third-party solutions out there that are recommended by Microsoft, this is a narrow way of thinking. Never discount the value of other people’s work. By designing your application to work with other applications already on the market, you can save time developing applications that already provide the functionality the organization requires. You may even find applications already that meet all of the requirements your organization needs. Not only can it save your organization or customer considerable amounts of money, it can save your team time to focus on other products that haven’t been developed, or require a more customized approach.

Finally, the use of poor design models and the complete lack of design are the last problems we’ll discuss here. New developers and those working on smaller projects can conclude that since it isn’t a big project they’re working on, design isn’t needed. As such, they take a “code by the seat of your pants” attitude, and later find problems cropping up that could have been resolved through design. When models are used for designing an application, new or theoretical models that work well in a classroom are used. Unfortunately, you can experience problems because these models are purely academic and/or untested. It’s for that reason that the models in the Microsoft Solution Framework should be adopted, as they’ve been used in the real world with success.

From the Classroom

Typical failure by design?

It is a common fact that a majority of application failures or flaws can be traced to deficiencies instituted during the design phase. Considering the importance the design phase places on the outcome of an application development project, traditionally low regard has been given to the ramifications of ignoring this phase of development.

Some of the most common pitfalls may have incredibly simple solutions. Yet it is the simplicity that often causes the development team or product manager to underestimate the negative consequences. The odds of failing to deliver the customer's expectations can quite often be significantly diminished simply by focusing on creating a clear and concise understanding of the project scope. For a product, clearly identifying the feature set to the mutual understanding of all parties involved can significantly reduce discrepancies in the future.

One potentially devastating issue involves focusing on using certain technologies simply to leverage existing skill sets, past the point of those skills producing a clear and distinct advantage. One common pitfall to avoid, therefore, is using a narrow focus when assessing the appropriate technologies to implement.

Given that proper design has produced a stable, workable, and efficient solution, failing to implement the necessary "open door" design policy can lead to significant scalability issues down the road. Failing to recognize design considerations that, given equal effectiveness, would produce a more scalable solution can severely crimp the ability to serve additional users when the application is a success.

Lastly, keep in mind that the strict adherence to separation of functionality between the different services in a multi-tier application can yield the same potential application inefficiencies that failing to consider adequate database denormalization may produce. Developing a strict division between user, business, and data services can lead the developer to make decisions that ultimately may actually produce a less efficient and possibly less scalable design.

     by Michael Lane Thomas, MCSE+I, MCSD, MCP+SB, MSS, MCT, A+

Microsoft's Process for Designing Solutions

As we saw in first few chapters of this book, the Process model describes the life cycle of a software development project. This life cycle lays out which tasks need to be completed, by breaking a project into four phases that culminate in milestones:

·       Envisioning Phase, which results in the Vision/Scope Approved milestone

·       Planning Phase, which results in the Project Plan Approved milestone

·       Developing Phase, which results in the Scope Complete/First Use milestone

·       Stabilizing Phase, which results in the Release milestone

Each of these milestones produces several deliverables, and is a point at which the development team synchronizes their efforts.

By outlining which tasks are performed at what time, and when efforts are to be coordinated and evaluated, these phases and milestones are a primary function of the Process model. However, this isn’t all the Process model provides to your project. As we’ll see in this section, the Process model has a number of principles and practices that help to ensure the success of your project, while providing flexibility to any project.

Interim Milestones

There are times when four milestones may not be enough. For delivery schedules that are over three months, you should consider establishing interim milestones. Interim milestones further break up a project, and provide additional points at which the team can synchronize their efforts. You can think of these as mini-milestones that occur between the major milestones of the Process model. By having interim milestones placed at regular increments in a project, your team can review issues concerning the project, coordinate efforts, and analyze whether each team role is performing to schedule. After reviewing these individual schedules, Program Management can then assess what impact certain issues will have on the delivery schedule as a whole.

There are two kinds of interim milestones you can apply to any project you’re working on. They are externally visible interim milestones and internally visible interim milestones. Which is used depends on a “need to know” basis. If the milestone applies only to members of your project’s team and customers, users, or stakeholders don’t need to be informed of the milestone, then it is considered internally visible. If you need to notify the organization itself about the milestone, then it is an externally visible milestone.

External interim milestones are known outside of the development team, and are announced to the organization. These include such things as meetings, where the team apprises customers and stakeholders of various aspects of the project:

·       Management review meetings, which are regularly scheduled to inform those attending about the status of a project, and review requests for changes in the product.

·       Post-functional specification baseline meetings, where those attending the meeting can approve freeze points in the functional specification of the product.

·       Review and validation of a draft functional specification. Before the functional specification is created, a draft is created. This includes interim delivery of models, user task analysis, and other elements that will be incorporated into the final specification.

As you can see, external interim milestones are a way of synchronizing team members and the organization as a whole, so that everyone has a clear understanding of what is required and what is being created.

Internal interim milestones are not known outside the development team. The reason that no one outside of the team requires knowledge of these milestones is that they are only of use for the team itself. Internal interim milestones are used to coordinate the team, or get a clear perspective on how their work is progressing. They include such things as synchronization points, incremental internal releases, and short-term interval deliverables.

Synchronization points are determined by Program Management, and used to coordinate the efforts of your project team. At these points, the data model, business model, user interface, and system architecture are discussed. These points ensure that the functional specification is being followed and understood by team members.

Incremental internal releases are, as its name implies, releases of the product that are used internally by the project team. For every internal release, the development team delivers a number of features in the product for testing. The thought behind the release is to treat the product as if it were to be shipped with just these features. If testable, the release goes through a test/debug/retest cycle, which allows the team to determine problems and progress associated with the product. If the quality is as good or better than expected, then it achieves a zero-defect milestone, meaning that it passed testing without any defects and developers can work on the next set of features. If it fails, the developers hammer out the problems of the original code, and the process repeats itself.

On the Job: It is recommended that you use intervals of every three months for your internal releases. If you choose to use a different and wider time span, remember not to space the releases more than six months apart. If you do, you’ll lose many of the benefits of incrementing internal releases.

Finally, short-term internal deliverables are used for assessing progress and risks of a project. As we saw in Chapter 4, each major milestone has a deliverable associated with it. By using internal deliverables that are made in increments of between five and ten days, the team can view how well they are proceeding before the major milestone is actually reached. This provides the team with realistic assessments of the project’s progress, as well as risks associated with the product.

How Milestones in the Process Model Map to Team Roles

Due to the close relationship the Process model has to the Team model, the MSF Process model also shows who is responsible for reaching a milestone. For a particular milestone to be achieved, certain tasks must be planned, managed, and accomplished. Team members are accountable for seeing that these tasks are completed successfully. If a team member fails in this responsibility, then the milestone associated with that member’s role isn’t achieved either. As shown in Table 6-1, this relationship allows us to directly map each team role to one of the four milestones in the Process model.

Milestone

Owner

Vision/Scope Approved

Product Management

Project Plan Approved

Program Management

Scope Complete/First Use

Development & User Education

Release

Testing & Logistics

Table 6-1: Each Team Role Owns Responsibility for Reaching a Specific Milestone

The Process model provides ownership of responsibility to the different roles in the Team model. Each team member owns responsibility for planning, managing, and accomplishing tasks associated with particular milestones. For a milestone to be achieved, the team members associated with that milestone must fulfill their specific responsibilities.

Scheduling

One of the more interesting aspects of a project is determining how long it will take for your team to complete tasks, so the product can be shipped by a specific date. The reason this can be so difficult is that the future is uncertain, and a schedule is a prediction of how long the tasks comprising your project will take to be completed. Proper scheduling is vital to the success of a project.

The Process model incorporates a number of proven disciplines and methods for scheduling, which helps ensure that your product is completed on time, and with little difficulty. One of the most basic principles in the Process model is the use of bottom-up estimating. Bottom-up estimates work on a chain-of-command principle, with those who are lower in a hierarchy reporting work estimates to those above them. As illustrated in Figure 6-1, you can think of bottom-up estimating as being a ladder, in which estimates are passed from the bottom rung to the top. Each estimate is passed to whomever is at the next level until it is finally combined at the top level. In other words, the people who actually do the work submit estimates to team leaders and management, and the estimates are then put together into a master schedule of the project.

Figure 6-1: Bottom-up estimating can be thought of as a ladder with each estimate being passed to a higher rung

The benefits of bottom-up estimates reside in having the people who have experience with a task determining how long it will take to do it. For example, rather than having someone with managerial background decide how long it will take to create a feature component, the developer in charge of that feature decides how long it will take to program it. Because the person responsible for the task determines the work estimate, this also makes them accountable for success in meeting that estimate. This provides motivation to produce in a specific time what they said they could do, and encourages members to try for early milestones.

The thought of bottom-up estimates can seem contradictory to the Team model, because it uses an obvious hierarchy, while the Team model views the team as a group of peers. However, even though the Team model is based on the philosophy of a group of peers, there is a hierarchy of what work is performed first, and which members are in leadership roles. When going through the different team roles listed in Chapter 1 of this book, you’ll see this hierarchy.

The first activity performed in a project is Product Management, which obtains the business requirements of a project, followed by Program Management, which has specific scheduling duties and determines when the product is delivered. The final activity in a project is Logistics, which ensures the smooth rollout of a product. In addition to this, Program Management has responsibilities over team leaders, who are responsible for feature teams, which developers are a part of. Though the hierarchy exists, the team is a group of peers, where the expertise of each member is put to the best use. The ladder analogy to bottom-up estimating in Figure 6-1 also helps in understanding the relationship Team model has with bottom-up estimating. If you think of house builders working on the ladder, the carpenter is no less important than the painter. However, the estimates of when the carpenter finishes affects when the painter can start, and when the work as a whole will be finished. Though these workers are peers and equally important to the project, their estimates are passed up the ladder and combined into a master schedule of their project.

Because the master schedule is comprised of estimated schedules and variables, it is important that the people doing work in these areas of the project create their own estimates. Estimates on the time each activity will take are submitted, and these are put together into a master schedule. Unfortunately, after estimates have been made and submitted, problems may occur, which can cause these estimates to be wrong. The Process model offers two methods of scheduling for an uncertain future. One of these is prioritizing tasks by how risky they are. This is called risk-driven scheduling. Using this method, a task is prioritized by the customer. The customer determines how important tasks are by technical and business risks associated with it. Features and services that are vital to the project’s success are given highest priority, and tasks that deliver less important benefits are given lower priority.

By prioritizing tasks involved in a schedule, the customer gains an understanding of what is risky about the project, while the team attains a clear vision about what features and services are important to the customer and end user. The team and customer gain a cohesiveness, and are able to decide which features will be shipped with the product, and when. In addition, since the team now knows which features are of high priority to a customer, they can give added effort to reaching early milestones for those tasks that are of greatest importance.

The other method is adding buffer time to your schedule. This is time that’s added to a schedule to cover problems that may arise in individual tasks. Program Management adds this time to the end of the schedule, rather than to each task in the schedule. The reason for this is that some tasks may come in on time or early, so it would be impossible to add buffer time to each activity the team works on.

When you add buffer time to the end of a schedule, it’s not an indicator that your team did a poor job of estimating the time it will take to complete different tasks. It is an acknowledgement that things happen that are out of your team’s control. For example, people get sick and miss time from work, some tasks are more complex than they originally appeared to be, requirements change, and so on. Because of this, it is impossible to merely add up the estimates the team members submitted to get an accurate ship date. Adding up such estimates should only be used to create an internal ship date that the team strives to meet while buffer time is added to this to create an external ship date, which is where the organization and/or customer sees the finished product.

Having said this, how much buffer time should be added to the schedule?  There is no set number of days, weeks, or months to add to project schedules, because each project you deal with is different. While some products may take a couple of month to finish, others may take considerably longer. Each product needs to be addressed individually, but you should expect approximately one-third of your total development time to be buffer time. If unplanned events occur during development, this buffer time will keep your schedule from slipping. If, however, there are no unplanned contingencies to affect the schedule, the buffer time won’t be used so your product will be ready for early release.

Fixed Ship Dates

When we discussed the Process model in Chapter 2, we saw how tradeoffs can be made between schedules, features, and resources. As shown in Figure 6-2, this creates a triangulated relationship between these three elements. Just as if a change in any side of a triangle changes the other sides, any change in schedule, features, or resources will affect the other two elements. As an example, if layoffs caused you to lose several programmers from a large project, you would have a cutback in resources. This means you would either have to trade off features available for the release you’re working on, or increase the time available to create the product. As you can see, trading off one element in the triangle affects the other two sides.

Figure 6-2: Triangulated relationship of features, schedule, and resources

Despite the tradeoffs available through this triangulated relationship, fixed ship dates can aid in getting a project completed rapidly and on time. When a fixed ship date is used, the schedule side of the triangle becomes fixed, and can’t be used as a tradeoff, unless of course, there is no other option except changing the schedule. Using a fixed ship date doesn’t mean that you’re carving a specific date in stone, and that missing this date will cause your project to fail. It means you’re agreeing that the schedule isn’t an element that can be traded off, and you’re going to shoot for a specific date to have the product shipped by. In short, it is a way of thinking, and not a method of determining exactly when the product will be ready.

This mindset allows team members to focus on delivering the product, rather than delaying delivery dates. The fixed ship date is achieved by using the bottom-up estimates and buffer time to acquire a date that the team believes is realistic to deliver by. The team can then get creative to meet this date, and force the tasks to be prioritized. Because the schedule can’t be pushed back, decisions must be made on how to produce the product by the set date. Any features that can’t be added to the current version are looked at as a possible addition to the next versions, allowing the team to deliver only the most important features in the current version.

One of the other benefits of the fixed date mindset is that it acts as a motivational goal. It’s a way of setting a personal goal for members of the team; they are going to push themselves to get things done by a specific date. This enhances morale in the team, because they have a tangible due date that they’re working toward. Since it’s agreed that the date isn’t going to be adjusted as a tradeoff, the team won’t feel like they’re going to have a career working on the same old project. They know when they’ll need to have the tasks completed, so they can move onto something new and fresh.

Breaking Up Large Projects

Just as a slipping schedule can dishearten a team, so can projects that are large and complex. Listings of what is to be included, known as the feature set, may be lengthy and difficult to follow, due to the sheer number of features to be included in the product. It can easily feel overwhelming when viewing the project as a whole. When this is the case, you should consider breaking the large project into subprojects.

By breaking a large project into groups of related tasks, team members are better able to focus on specific aspects of a project. For example, let’s say you were creating a calculator program for use by different types of users such as accountants, programmers, and networking people. You could split this project into subprojects of creating a financial calculator, programming a calculator, a component that calculates subnet masks, and so forth. This could further be split up into user interface, storage of user preferences, and so on. Rather than taking on the entire project in one fell swoop, developers can focus on the subproject of creating a group of features.

One of the benefits of breaking up projects is that developers are able to see small successes building toward a completed project. There is a certain amount of exhilaration in seeing that a subproject works, and knowing that you can now move on to the next stage of development. If there is a problem, it is easier to isolate it in these small feature groups than in large projects. These internal releases allow you to correct a problem before it affects the project as a whole.

Daily Builds and Smoke Tests

Imagine you’re a teacher who doesn’t believe in giving tests. When your students take their final exam, the class fails because they didn’t understand the information you were attempting to put into their heads. If you had tested your class regularly, you could have caught and fixed this quickly. This little parable illustrates why daily builds and smoke tests are important in a software project. Daily builds and smoke tests are where you build your program daily by compiling it, and then run a series of tests on it to ensure that it functions as it should. Like the tests you took in school, the daily builds and smoke tests allow you to see problems quickly, and fix them before they get out of hand.

A daily build is where you build your executable program by compiling it. This allows you to see that the application compiles and links its files and components without errors. Once compiled, you can then determine if the program launches properly, without locking up the system or causing other unexpected events. Each day sections of code completed the previous day are added to the build. If the daily build works one day, and not the next, it can be determined that part or all of the code integrated into the current build is causing the problems.

Before performing a daily build, and making changes to erroneous code that causes problems, you should ensure that the project has been added to Visual SourceSafe (VSS). Visual SourceSafe comes with Visual Studio 6, and allows you to add files from your project to a database. If changes are made to your project files, and those changes cause problems, you can restore a previous version of the file. Since these previous versions were saved to the VSS database before the changes were made, you don’t have to remove your changes before attempting to solve problems in your code in another way.

Exam Watch: Microsoft makes a valid point of stressing that a daily build is just that—it is built daily, and not weekly or monthly. Spreading out the builds over longer periods of time loses the benefits acquired from doing it in the first place.

In creating such daily builds, the code that’s completed to date is added and compiled. This doesn’t mean every line of code that was written the previous day, but all of the code that’s considered complete and doesn’t require any additional work. Once a developer is finished with a procedure, it is integrated with the daily build files and compiled. This keeps the development team from feeling that they need to complete everything they’re working on in a day, or deciding not to start sections of code that won’t be ready for the next day’s build.

Once this is successful, you’re ready to start the smoke test. A smoke test is used to detect major problems that go beyond seeing if the software launches properly. Because of this, a daily build isn’t really valuable without a smoke test. While your application may compile without error, and create a nice little .exe file that launches correctly, the build doesn’t tell you if the program performs the functions its designed to do, or if it “smokes” the computer system by causing major damage. The smoke test acts as the first real testing an application will experience, and keeps your program from deteriorating because of bad code being continually added.

A smoke test evolves with your software product. While an initial smoke test may be small, and determine if the words “Hello World” appear on the screen, it may take a considerable amount of time to do a smoke test later in the project. Therefore, you should consider creating an automated smoke test that checks major parts of your application without user intervention. That way you won’t be required to spend a large amounts of time, 30 minutes, an hour, or more, determining if your program passes the smoke test.

In addition to testing the integrated code of your development team, you should have each developers smoke test their own code. This ensures that the code is stable on its own, and won’t be a problem in itself when integrated with the code of other developers. However, just as adding comments to code is heavily advised, and often overlooked, its not uncommon for developers to infrequently build and smoke test their code. After all, the real fun in programming is programming. However, if you have a developer who isn’t performing daily builds and smoke tests of their own code, you should consider that person’s work to be risky (at best).

On the Job: When possible, a separate computer should be used for code that’s integrated for daily builds and smoke tests. This computer shouldn’t have anything important on it, as you’re not only testing to see that the major functionality of the program works, but also checking to see that the program doesn’t harm the system. The last thing you want is to have a bad section of code reformat the hard drive of your network server, destroy critical information, or some other nasty event.

The daily build and smoke test should not be considered a replacement for the Testing role of the Team model. By performing daily builds and smoke tests, you’re ensuring that the product is stable enough to reach an interim milestone. The daily build and smoke test is used to see that the software compiles and links files and components, launches correctly, and performs its activities without harming the system. After all, if the program won’t start, harms the system, or doesn’t have basic functionality, the people in Testing won’t be able to do much. If Development can perform smoke tests without problems, then when completed, the application can be passed on to Testing to check for problems beyond this fundamental functionality. If it doesn’t succeed in meeting the requirements of the daily build and/or smoke test, then the team must consider debugging or redesign.

How Solution Design Relates to Enterprise Architecture

An enterprise is a business, such as a corporation, that uses computers in a network or an interconnected group of networks that can span different geographical areas. Usually the network will consist of a variety of platforms, operating systems, protocols, and/or network architectures. In creating enterprise applications, you’ll need to design your software product for such things as networks, corporate intranets, or the Internet. Unlike desktop applications, enterprise applications can be split so part resides on a server, and another part resides on client computers. Hundreds or thousands of requirements may need to be addressed by the application, as users access the application and data on the server application.

This kind of development requires an understanding of the architecture of the enterprise’s system of computers, and solid design models for creating these large applications. The Microsoft Solution Framework’s Solution Design and Enterprise Architecture models provide the means of creating such applications. As we’ll see, these models makes the design process easier by splitting large projects into smaller pieces, and promote the use of COM components. In using these models, any large project becomes much more manageable.

Modular Design and the Solutions Design Model

Modular design involves breaking a large project into manageable chunks called modules. These modules are designed to perform different and specific tasks and functions. They can be developed and tested individually, and then combined into the final project. Because you design modules as standalone components of a project, the code can be reused in different products that require the same functionality. In addition, by incorporating business rules into these components, you don't have to rewrite each application that uses the rules; you merely rewrite the code in the component that contains the business rule that needs changing. This saves you the trouble of having to rewrite the same code over and over in different projects, or different areas of the same program.

Using modular design requires implementing such things as stored procedures and components. Components are written with Class models, and use the Component Object Model (COM). An example of a COM component is an ActiveX component. Such components allow you to split an application so that parts are spread across a network or a computer. These components are reusable and accessible to other programs. By using this method of design, you can split the design of your solution into two main tasks: creating reusable components (ActiveX, stored procedures, and so forth), and integrating those components into your application.

When you design an application with components, you need to determine and then organize or separate the customer’s requirements. In doing so, you decide what each component will do, and what each component will require. This is where the Solutions Design model comes into play.

The Solutions Design model is highly focused on addressing the requirements and limitations of the customer, user, and the enterprise itself. As we’ve mentioned in previous chapters, the user and customer aren’t necessarily the same person or people. The customer is the person who’s paying you to create the software, while the user is the person who actually uses your business solution. In designing a business solution, you need to address the issues regarding them, as they are the ones using and/or paying for the application. Because of this, the Solutions Design Model has the customer and user involved in the design process. They are invited to address such key issues as usability and requirements, so you can determine how the application will be used and consequently it will increase productivity. By involving the user, it keeps them from experiencing problems later, having to rely on a help desk for assistance, or not using the product at all.

In addition to the user and customer, the enterprise as an entity has its own requirements and limitations. In designing business solutions, you’ll need to look at such things as what the organization does, what it produces, and what limitations will affect development. These limitations include such things as legal issues (e.g., including a certain percentage as tax to a price), business rules that determine how data is accessed, or technical issues like the network, operating systems, and hardware being used. Thus, you apply the needs of users and customers to the constraints of the organization.

On the Job: While the Solutions Design model has you determine the requirements of the user, customer, and enterprise, there are often times when the three don’t agree. Customers may want features that users don’t, while users want features that your customer sees as unnecessary. To add to this, business rules, legislation and standards, or technical limitations may negate the wishes of the customer and user. In designing an application you act as an advocate for each group. Because the application is useless if it doesn’t adhere to business practices, laws, or technical requirements, the enterprise should always be given priority. Since the software must be usable, the user should rank second in importance. You should always try to address these needs to the customer in an accessible manner. However, in the end, it’s important to remember that the customer is the person signing your paycheck. In the end, regardless of the business’s requirements and the needs of the user, it is the customer who has the final say.

The Solutions Design model brings together several other models in the Microsoft Solution Framework, to enable you and your staff to focus on where resources should be used to produce the most value and provide the most return. The models incorporated by Solutions Design are the Process, Team, and Application models. As we saw in the previous section, the Process model maps out the process of a successful software project, and the Application model helps you create flexible designs. The Team model is used to organize people who will be working on the project into a high performance group of peers. When used with the Solutions Design model, you have the foundation for a successful project that will anticipate user needs, and adhere to the requirements of the business and customer.

To identify the requirements of a project, three different perspectives are used in the Solutions Design model: 

·       conceptual design

·       logical design

·       physical design

These perspectives help focus the design process by identifying the business and technical requirements of a software development project. By understanding these requirements, you are then better able to assign the resources necessary for your project’s success.

The conceptual design perspective is where the needs of the customer and user are determined, and the initial concept of the solution is conceived. Information gathered on what the user needs to do is applied to the requirements of the product. The conceptual design is non-technical. It details such things as the functionality of the application, how it will interact with the end user, and criteria for performance. Scenarios and models are used to relay the information so that team members, customers, and users can understand what’s needed.

Once this information has been gathered, it can then be applied to the logical design perspective. Logical design is where user requirements are applied to the technical know-how of the team. In logical design, the structure and communication of elements making up your application are laid out. These elements include such things as objects, component and application structure, user interface, the logical database, and various services supplied and consumed by your application.

Once the requirements of the conceptual and logical design are established, the physical design perspective is used to put these needs into a tangible form. In physical design, the constraints of technology are applied to the logical design of the solution. It is used to define how the pieces that make up your business solution work together. This includes such elements as the physical database, user and programmatic interfaces, and other components. In determining this, issues like performance, implementation, bandwidth, scalability, reliability, and maintainability are resolved and implemented. Because this perspective applies previous designs to a concrete form, you are able to estimate what resources, costs, or scheduling will be needed to complete the project.

In working through the three perspectives that make up the Solutions Design model, you don’t necessarily need to complete work in one perspective before moving on to the next. There isn’t a specific cutoff point between one perspective and the next that allows you to have one part of a solution being coded while another is being designed conceptually or logically. As we’ll see in the chapters that follow, the major separation between these perspectives are where specific tools are used in design. For example, in conceptual design, no development or development tools are used. Instead, word-processing, project management, financial modeling and planning, accounting, and other management information tools are used. While Visual Studio offers none of these tools, Microsoft Office, Microsoft Project, and other application packages are utilized. The benefit of being able to overlap these perspectives is that you can return to the different design perspectives as many times as necessary. In doing so, you can revisit, refine, or even redesign your solution without compromising the project as a whole.

Enterprise Architecture

When you think of architecture, you probably think of structures designed by architects, and you’d be right. Architecture is the art and science of building, and it is also the method whereby the components of a system are organized and integrated. Enterprise Architecture deals with the planning and design of systems, utilities, infrastructure, and processes that support a business’s needs and the business units of the organization. This involves planning the architecture before building it, as well as setting standards and guidelines to support the application and infrastructure systems.

The Enterprise Architecture model integrates the business by ensuring that changes made to the enterprise are consistent and meet the business’s needs. This means elements of the architecture such as data management policies, APIs, and technical specifications are the same in each department of the organization. Rather than having one set of standards and guidelines for each area of the enterprise, it is consistent across the board. As we’ll see, the model does this by not only looking at the current state of the organization, but where they are going or want to be in the future.

The Enterprise Architecture model also provides the guidelines you need to plan, build, and manage technology infrastructures. It is used when your team needs to do such things as design an intranet, plan a network architecture, or build a messaging infrastructure or electronic commerce site. This model aids you when you need to plan the technology that will be used to support and solve an application’s requirements.

Like the Solutions Design model, the Enterprise Architecture model is comprised of different perspectives, which allow you to look at an enterprise from diversified viewpoints:

·       Business Architecture, which defines the business and its requirements

·       Application Architecture, which defines an organization’s application portfolio

·       Information Architecture, which defines the what an organization needs to know in running its processes and operations

·       Technology Architecture, which defines the hardware and software in an organization

Though comprised of four perspectives, it’s important to remember that when using the Enterprise Architecture model, you’re dealing with a single architecture that’s being looked at in different ways.

Exam Watch: To remember the different perspectives in the Enterprise Architecture model, remember the word "BAIT,” with each letter representing the words Business, Application, Information, and Technology.

Business Architecture

In comparing the Business Architecture perspective to the Conceptual Design perspective of the Solutions Design model, it’s easy to see a correlation. It is through these perspectives that the team acquires an understanding of project requirements. The needs of an enterprise application’s users are obtained, and models that communicate the requirements addressed by the project are generated. Each perspective is the starting point to designing solutions that address specific business needs.

The Business Architecture defines the business and its requirements. It is here that you determine what problems an organization is experiencing, what they do, and what they require. This information is gathered by asking and answering such questions as:

·       What does the enterprise do?

·       What does the enterprise hope to achieve?

·       What are the organizational structures of the enterprise?

·       How do the elements in the three previous questions interact with one another?

Without knowing the information gathered from these questions, you will have an unclear view of what’s required from your team. Information gathered through this perspective is what drives enterprise application development. After all, before you can solve business problems, you need to understand its requirements, and how the business works. Because Business Architecture is the foundation that an application or infrastructure is built on, any work you do after gathering information at this stage should trace back to the problems and requirements of the business.

Without knowing what an enterprise does, you won’t be able to address the specific needs of the organization. It’s important to understand what products and services are created, provided, and/or sold by an organization. This information has a direct impact on the requirements of the enterprise architecture, and the applications or infrastructure you’ll create, manage, or upgrade.

If you don’t understand the high-level goals and objectives of an organization, it doesn’t matter what course of action you take. Therefore, you must discern what the organization hopes to achieve if you’re going to move the enterprise from its current to future state.

It may seem strange that you need to inquire about the enterprise’s major organizational structures. After all, what does that have to do with applications and infrastructure? The answer to is, a lot. This information can affect issues such as security, which affects who will require access to certain resources or features, or even if such issues are relevant to an application or infrastructure. In addition to this, it will affect who your team deals with, the chain of command in dealing with problems, who will interact with the team on the project, and so on.

As the Enterprise Architecture uses the milestones of the Process model, this perspective corresponds to the envisioning phase. The information gathered on business requirements is used to create a vision statement, which outlines the assumptions and expectations of the project. Any information on the process is used for revising the vision statement. This is an informal document, and is reviewed and revised until a balance of what is desired and what can be delivered is achieved. As you’ll remember from Chapter 2, by balancing these optimistic and realistic viewpoints, a shared vision of the project is achieved. By identifying and setting priorities for the project, the result is a vision/scope document that outlines the details of what a project entails.

In addition to these documents, the Business Architecture perspective includes a number of other tasks and deliverables. It is through this perspective that you determine the costs involved in the project, plan and maintain a budget, determine business projections, negotiate contracts, and manage personnel. In addition to these tasks, the Business Architecture perspective results in the creation of a business case, which is maintained and updated as the project progresses. A business case is a plan of action that’s presented to senior management, and backs up a proposal for a project by providing facts and evidence about the project, and how it will be approached. For more information on business cases, review Chapter 2.

Application Architecture

The Application Architecture perspective defines the application portfolio of the enterprise. In other words, it looks at what applications and application models are currently used in the enterprise, and then uses this information to determine what work needs to be performed by the team. When you consider that the purpose of a software development team is to develop software, it may seem strange that a perspective even exists that looks at other applications and models. However, in doing any work, you need to understand where you are before you know where you’re going. Information gathered through this perspective allows you to see what work needs to be done, and determine the resources available to your team.

Application Architecture defines the interfaces and services needed by a business, which is translated into development resources that are used by project teams. In other words, the user and programmatic interfaces determine the component and code libraries you’ll use for your application, as well as standards documents, design guidelines, and models. It is important to determine the application models currently used by the enterprise, to see if they are compatible with the MSF models we’re discussing here. There are older systems out there that use application models that trace back to the 1960s or earlier, and are in dire need of replacement. Ones that aren’t quite so out of date may simply require revision. The Application Architecture provides the guidelines necessary for moving to new application models.

Through the information offered with this perspective, you can determine where application backlogs exist, and if new applications are required. This allows you to decide on whether an application needs to have its code revised, or if there is a need to create brand-new applications that adhere to new standards and have better performance. For example, if the network is slowed because of 16-bit applications designed for Windows for Workgroups, you would either revise the code or create new 32-bit applications for newly installed NT Workstations and Servers. Based on the priorities you set in the Business Architecture perspective, and the automated services that support business processes, you can determine how to approach a particular project.

In addition to aiding you in the applications your team creates, this perspective also has you look at whether your team should bother creating a product. Due to the number of software products on the market, you should investigate whether it would be better and cheaper to purchase software that’s already developed from third parties. By simply examining what’s already on the shelf, you may find that there are applications that provide the same (or better) functionality as what your organization wants you to create. In such cases, it may be more affordable to simply purchase the third-party product.

On the Job: Never underestimate the value of steering your customer toward software that’s already out there. Many developers forget that customers aren’t as savvy with what’s available, and assume that the reason they’re being hired to create software is because software already on the market has been dismissed by the customer. For example, a customer may want you to create a spreadsheet program, and after discussing the requirements, you may realize they’re talking about a product identical to Microsoft Excel. Rather than recreating the wheel, you could charge a consultation and go on your merry way. By suggesting software that’s currently available to the customer, you may save them a considerable amount of money, and save yourself unnecessary work.

Because your application needs to become part of a system, and users have come to expect applications to integrate with their operating system and other applications, the Application Architecture perspective provides information on integration issues unique to the current system. Using this perspective, you can determine what issues will affect integration of a new application with a system.

This perspective corresponds to the Logical Design perspective of the MSF Solutions Design model, in which objects and services are determined and laid out. As we saw previously in this chapter, this includes defining the business objects, interfaces, services, and dependencies in the system. Information gathered through the Application Architecture perspective can be directly applied to Logical Design.

Information Architecture

Like Application Architecture, the Information Architecture perspective correlates to Logical Design. This perspective describes what the company needs to know to run the organization’s business processes and operations, and how data and information is handled in an organization. Information gathered through this perspective is applied to laying out such things as logical databases, and determines such elements as functional data requirements, information needs, policies dealing with data management, and how information is bound to workflow.

Because the meat and potatoes of every business application is accessing and manipulating data, it is important to determine where data resides in an organization. It is important to remember that data stores—databases, documents, spreadsheets, and so forth—exist not only on servers, but on the desktop computers prevalent in most enterprises. If a software product needs to access such data, you must first determine where it resides. This will affect what features will be included in your application, whether components that implement COM and DCOM will be required to access data in various locations, and how your application will be designed. The Information Architecture perspective addresses these issues by identifying where most of the critical information in an organization resides.

Technology Architecture

The Technology Architecture falls hand in hand with the Physical Design perspective of the Solutions Design model, where Logical Design is applied to the real-world constraints of technology. Technology Architecture is what provides standards and guidelines for laying out the software and hardware supporting an organization. This is important because it is the technology that determines whether elements of your application, or the software as a whole will run. For any software product, there are requirements that must be met if the application is to function. These can include the following:

·       operating system

·       client/workstation tools

·       network connectivity components

·       hardware used by workstations and servers

·       modems

·       printers

·       other peripheral devices, software and hardware components

In looking these over, you may assume that all software must involve each of these elements. This isn’t necessarily the case. For example, one software project may require the use of a modem, while another project you’re working on does not. As you can see, different projects may use different technologies. With the Technology perspective, you acquire a vendor-independent, logical description of your organization’s technology infrastructure. This allows you to determine if the infrastructure will need to be updated to support new applications, or if the functionality of new applications created by your team will need to be limited.

Beyond the actual hardware and software requirements that support the Application and Information perspectives, the Technology perspective defines the standards and services of the technology needed to support your organization. These include such things as APIs, network services, topologies, and technical specifications.

What is modular design?

Modular design breaks up large projects into smaller chunks called modules. They are designed to perform a different function or task, and can be developed and tested independently of one another, then combined into the final project. By designing these modules as standalone components of a project, they can be reused in other projects that require the same functionality.

How much buffer time should I add to my project’s schedule?

About one-third of your total development time should be buffer time. This covers time spent dealing with unplanned events or occurrences.

What are the four perspectives of the Enterprise Architecture model?

The four perspectives of the Enterprise Architecture model are Business, Application, Information, and Technology (BAIT).

What perspectives make up the Solutions Design model?

The Solutions Design model is comprised of the conceptual, logical, and physical design perspectives.

When should I use interim milestones?

The buffer time involved with using interim milestones is a variable that generally needs to be determined from project to project. As a rule of thumb though, if your project has a delivery schedule greater than three months, you should consider using interim milestones.

Exercise 6-2: Determining the Appropriate MSF Design Phase

In the second column, fill in the appropriate phase that corresponds to the architecture from the first column.

Architecture

MSF Solutions Design Phase

Application

 

Business

 

Technology

 

Information

 

Answers to Exercise 6-2

Architecture

MSF Solutions Design Phase

Application

Logical

Business

Conceptual

Technology

Physical

Information

Logical

Certification Summary

While there are numerous pitfalls you can encounter in a project, you can avoid many, if not most, of the problems by knowing what common problems to avoid, and using proven models that aid you in software design. The Microsoft Solution Framework provides models, practices, and principles that aid you in the design of applications and component solutions.

The Process model defines the life cycle of a project, by breaking your software project into four phases. These phases culminate in major milestones that allow a team to coordinate their efforts. In cases where you’re working on complex projects with long delivery schedules, interim milestones should be placed at regular intervals in large projects. If your project has an overall delivery schedule of three months or more, you should give serious consideration to setting interim milestones in your project.

In addition to the use of milestones, the Process model aids in getting your application completed rapidly and on schedule. Risk-driven scheduling prioritizes the tasks associated with a project, while buffer time provides additional time to a project to deal with unforeseen events. Bottom-up estimates allow the people doing the work to create their own work estimates. Tradeoffs can be used to sacrifice one area of a project to keep other elements on track, while fixed date mindsets keep your schedule from being sacrificed as a tradeoff. Finally, to ensure your product is properly constructed during the course of the Process model, daily builds and smoke tests are used.

The Solutions Design model is comprised of the conceptual, logical, and physical design perspectives. Through this model, users become part of the design process by putting forth the requirements they feel are necessary in the product. The different perspectives of this model shouldn’t be thought of as stages with clear cutoff points, as they allow the team to revisit, refine, and redesign perspectives at any point in development.

The Enterprise Architecture model integrates the business by ensuring that changes made to the enterprise are consistent and meet the business’s needs, and provide the guidelines you need to plan, build, and manage technology infrastructures. This model consists of four perspectives: Business, Application, Information, and Technology (BAIT), which provide different ways of looking at the architecture.

Two-Minute Drill

·       Rather than being a static methodology, MSF is a framework of models that can be adapted and applied to an organization’s specific needs.

·       Of all the possible problems you can encounter in designing an application, the most common one you’ll experience is the design failing to deliver what the customer expected.

·       The second most typical problem in design is using inappropriate technologies to complete the project.

·       Interim milestones further break up a project, and provide additional points at which the team can synchronize their efforts.

·       There are two kinds of interim milestones you can apply to any project you’re working on: externally visible interim milestones and internally visible interim milestones.

·       External interim milestones are known outside of the development team, and are announced to the organization.

·       Internal interim milestones are not known outside the development team. The reason that no one outside of the team requires knowledge of these milestones is that they are only of use for the team itself.

·       Synchronization points are determined by Program Management, and used to coordinate the efforts of your project team.

·       Bottom-up estimates work on a chain-of-command principle, with those who are lower in a hierarchy reporting work estimates to those above them.

·       A daily build is where you build your executable program by compiling it.

·       A smoke test is used to detect major problems that go beyond seeing if the software launches properly.

·       Modular design involves breaking a large project into manageable chunks called modules. These modules are designed to perform different and specific tasks and functions.

·       The conceptual design perspective is where the needs of the customer and user are determined, and the initial concept of the solution is conceived.

·       In physical design, the constraints of technology are applied to the logical design of the solution. It is used to define how the pieces that make up your business solution work together.

·       Enterprise Architecture deals with the planning and design of systems, utilities, infrastructure, and processes that support a business’s needs and the business units of the organization.

·       The Enterprise Architecture model is comprised of different: Business Architecture, Application Architecture, Information Architecture, and Technology Architecture.