- ~ Posted by Deepak Kamboj on March 11, 2010
A Data Architect is an increasingly important role.
It is a natural evolution from Data Analyst and Database Designer, and reflects the emergence
of Internet Web Sites which need to integrate data from different unrelated Data Sources.
These Sources can be either :-
external, such as Market Feeds,(e.g. Bloombergs), and News Agencies,(e.g. Reuters). Internal, such as existing systems, such as HR for Employee details. The Data Architect will work closely with the Users, systems designers and the developers on a Project team.
To get an idea of the skills the Data Architect should have, check out this Page with typical adverts from www.monster.com
Vision - The Data Architect needs to be able to have an end-to-end vision, and to see how a logical design will translate into one or more physical Databases, and how the Data will flow through the successive Stages involved. He (or she) will need to be able to address issues of Data Migration(Validation, Clean-up and Mapping), and will need to understand the importance of Data Dictionaries.
The appropriate Attitude should include :-
An Enquiring Mind The ability to abstract general principles from specifics. A strong desire to establish Standards of Best Practice. Recognition of the value of Data Architecture Design Patterns The required Skills include :-
Data Analysis Data Migration Tools Knowledge Data Modelling Data Integration Data Warehousing Database Design etc.. Personal Qualities should include :-
Communications and Presentation Skills A Good team Player Good relevant Books are hard to find :-
Maybe I should write one, in the meantime, I have put together a small list, although they are primarily about Enterprise Architecture. Good relevant Organizations are also in short supply, so here are a few that might be worth joining.
Training is also in short supply. The best way to get an idea of the best training is to check some job adverts for Data Architects. Then plan your training accordingly, depending on how your strengths and weaknesses compare with the requirements.
Here's a Page with typical adverts from www.monster.com
Salary.com provides the following Job Description for a Data Architect III (Senior Data Architect) :-
Designs Data Architectures. Designs and builds relational databases. Develops strategies for data acquisitions, archive recovery, and implementation of a database. Cleans and maintains the database by removing and deleting old data. Usually requires a degree in an appropriate area and at least 5 years of experience in a related area. Be able to design and develop Databases, Data Warehouses and Multidimensional Databases. Relies on experience and judgment to plan and accomplish goals. May lead and direct the work of others. Typically reports to a project leader or manager. A wide degree of creativity and lateral thinking is expected.
Trackback: http://www.databaseanswers.org/role_of_data_architect.htm
- ~ Posted by Deepak Kamboj on February 24, 2010
What is a Solution Architect?
The essence of the Solution Architect (SA) role is the conversion of the requirements into an architecture and design that will become the blueprint for the solution being created. This conversion is based largely upon the previous design patterns that the SA has been involved with in the past through reading and staying abreast of the latest techniques, or through personal experience.
It is this conversion part of the role - the role of the SA -that most often is underestimated in its complexity. Just as the ability of the Functional Analyst to create a requirements document is one part science and wrote procedure so is the creation of the architecture. The rest, however, is an art form. Creating effective architectures to create a solution requires the careful balance of dozens of development concepts ranging from "Keep it Simple Stupid" to "Fail to Safe".
In the process of converting requirements to an architecture there are often parts of the SA's role which seem out of place. For instance, there is often a fair amount of research that happens during this phase. The research may be targeted at testing a technology that will become critical to the architecture. For instance, the SA may test to see if USB or serial port access is available from Java if there's a need to read a device without downloading software. This process can either be done alone or depending upon the size and velocity of the project can be delegated to a development lead.
In addition to research on technologies and approaches critical to the architecture, there is often a review of patterns that might be useful to the architecture. Patterns are previously described and validated approaches that can be used to create portions of the solution. Patterns are released through research and can come from places such as Microsoft's software development libraries. Reviewing the pattern allows the architect to refresh their memory on the details of the pattern and to evaluate what additional guidance they will have to provide if they choose to use the pattern.
The final component to the role of solution architect is the motivation and guidance of the development leads. Development leaders need to buy into and accept the architecture, to know how the pieces will fit together at a high level. They must also see the art portion of the architecture to get an appreciation of the subtle nuances of their portion of the architecture. It's the art portion of the architecture that makes it elegant. That elegance helps to maintain cohesion between various parts of the design and encourages simplicity. It is necessary for the lower level design and approach to match the higher-level architecture for the solution to be cohesive. Once the development leader has internalized their portion of the architecture the SA must continuously motivate and reinforce the good work that is being done. They must continue to motivate the Developer Lead(s) to push through tough issues and create the solution.
Getting Started as a Solution Architect
For most people becoming the SA on a large project doesn't just happen. It's not like winning the lottery where one day your name is drawn out of the proverbial hat. It is, instead, a slow steady progression of learning and developing. A person may find their way to this coveted role within only a few years of professional experience but more frequently it takes a dozen or more years to consistently find themselves in this role.
The starting point is generally being the only person on a very small, and sometimes insignificant project. The project may be small enough that a single person may fill every role - including the role of solution architect. These little projects can even be ones where the organization hasn't identified the project as something that needs to be done yet but are items that a member of the software development team realizes that would be helpful.
Another approach to becoming a SA is to become a distinguished Development Lead (DL). The SA role and the role of the DL are very similar in the skill sets needed. The SA skill set is slightly broader and requires a bit more finesse, however, fundamentally the same. The SA lays out the architecture for the overall solution whereas the DL converts that architecture into detailed design. One approach to getting started as a SA is to become a DL and work towards the additional skills that a SA possesses. Most SAs have that ability to give some of their work to DLs looking to step up.
One of the ways to demonstrate an interest in the SA role, no matter what role you may currently be filling is to invest time in learning patterns. Because patterns form the basic building blocks of nearly every architecture, learning patterns makes it far easier to identify where they can be helpful. Also, reading books and articles on different architecture perspectives and new development techniques can broaden your point of view and allow you to see opportunities to create your own small sections of the solution.
The distinction between a development lead and the SA are often subtle. Where the development lead focuses on detailed knowledge of a particular area the SA is very broad. This allows the SA to view the problem from a different perspective. Instead of getting mired down into the details of implementing one specific thing the SA focuses on integrating various parts of the solution into one cohesive network that solves the larger problem.
The other subtle change is in accountability. While the development lead is responsible for their part of the solution, the SA is the proverbial one neck to choke if it doesn't all come together right. The SA has the ultimate responsibility for making the technologies work together. As a result the SA role comes with a requisite level of responsibility for the success of the project.
What's in their Toolbox?
The toolbox of a SA has more tools in it than most other roles. Most SAs have grown up in the software development world and have learned dozens of tools designed to help them be more productive.
Perhaps the most important tool in the toolbox is a visual documentation language, such as UML. The UML structure for describing a variety of different views of the software development problem in pictorial form is the most recognizable visual documentation language for developers. The SA should be familiar with each of the various UML forms and have expertise in the development of use cases, class diagrams, and occasionally state diagrams as well. Mastery of UML allows quicker, easier, and better communication with the DLs and the developers.
In addition to UML, the SA may need to be good at database design. Because most of the time the way that data is stored and retrieved is integral to the success of the solution, knowing how to design a database to hold the information is a critical part of the solution being successful. SAs know how to create databases and optimize them for good performance.
In addition to mastery of UML and database design, it's sometimes necessary for the SA to have experience with specific tools and processes when the organization has decided upon a specific process for software development. The most common software and process is the Rational Rose Unified Process. Other tools and processes exist the ones that the SA will have to master are based on what the organization has chosen.
Perhaps the most critical skills for the SA are the ability to create consensus and understanding around the architecture. While a development lead my need to involve a few people in their detailed design the architecture of the application touches every member of the team and there's a need to get them to understand it and agree with it. Once the SA has created the architecture it's time to communicate and sell it.
Where's the position heading anyway?
There is a great deal of pressure in the US to move development to countries with cheaper labor. While the SA role could be outsourced, , there is some insulation because of the need to work closely with the Functional Analysts in the gathering and organization of requirements. The distributed software of the global world requires more effort on the part of the SA and increases their need.
The overall need for SAs will continue to increase as the problems that the SMEs present are more complex and thus they require more complex solutions. The more complex the solution, the more SAs will be required to create it.
The software development tools were supposed to reduce the effort of the SAs and therefore reduce their need for the role, however, that increase in efficiency has been far outstripped by new demand.
The Good, the Bad, and the Ugly
- Good: Key, High-Value Position - The SA is a key role and one which can provide immense value if done correctly. This generally means a healthy salary.
- Good: An SA is likely to get to interact with many of the key members of the development team as well as key members of the user community. This makes it a very visible position.
- Bad: Hard to keep up - Being a SA means keeping up to date on a wide variety of new techniques, patterns, and tools. The effort to keep up can be very draining at times.
- Bad: Difficult to get right - The role requires balancing so many factors that it's difficult to get right. In other words, it's easy to fail.
- Ugly: Requirements - Although a good Functional Analyst can provide great requirements a moderately skilled one may not. The difficulty is that most people, including seasoned SAs, have trouble spotting bad requirements documents before it's too late. The SA must always have to consider that the requirements may require the SA to do a lot more research and legwork into what the client really needs.
- Ugly: If a project fails, the SA is at the top of the list for people to blame.
Conclusion
The solution architect role may be the most sought after role in the software development process but it's not without its challenges. Learning the broad array of skills, shouldering the responsibility, and dealing with the consequences can be more than the average mortal may want to take on.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking. You can reach Robert at Robert.Bogue@CroweChizek.com
Backtrack: http://www.developer.com/mgmt/article.php/3504496/Anatomy-of-a-Software-Development-Role-Solution-Architect.htm
- ~ Posted by Deepak Kamboj on January 26, 2010
Software development is done differently at every organization, and in every home office throughout the world. The process that one organization or person uses to develop software may work for their specific environment and situation but may fail miserably in another set of circumstances.
It is, in part, the differences in environments which make it so difficult to quantify the process of software development in a single set of terms that all practitioners can agree to. As newer approaches appear on the scene, such as extreme programming and agile development the perspective of the world on what the process should look like changes slightly or dramatically.
However, despite these changes there are some things that remain the same. There will always be a need to understand the business problem, convert that problem into an architecture, convert the architecture into a solution, test the solution, and deploy the solution. Although each of these processes may change to some extent based on the programming models and tools being used, fundamentally there are some roles, which every process has in one form or another. One person may be filling all the roles or a handful of the roles, or one very specific role. Despite this there is a need for all of the roles - each serves a purpose. The origanization chart below gives you an idea of how each position fits together within an organization.
Common Roles
There is a series of roles that exist in most software development processes. As mentioned above one team member may be filling many roles and some roles may be suppressed for a specific type of project but all of these roles exist in one form or another in every software development project:
Click here for a larger image.
- Subject Matter Experts (SMEs) - The subject matter expert is the person or persons from which requirements are captured. These are the people who know what the software needs to do and how the process works. The SME role is somewhat different from the other roles because it is constantly changing as new clients (internal or external) are brought in to help design a solution. SMEs are rarely from IT - except when the solution is being designed to support IT. SMEs are most frequently the person who will receive the benefit of the system.
- Functional Analysts (FAs) - Functional analysts have the unenviable roles of eliciting clear, concise, non-conflicting requirements from the Subject Matter Experts who may or may not understand how technology can be used to transform the business processes in a positive way.
- Solutions Architect (SA) - The technical architect is responsible for transforming the requirements created by the Functional Analysts into a set of architecture and design documents that can be used by the rest of the team to actually create the solution. The Solutions Architect is typically responsible for matching technologies to the problem being solved.
- Development Lead (DL) - The development lead's role is focused around providing more detail to the Solution Architect's architecture. This would include detailed program specifications creation. The Development Lead is also the first line of support for the developers who need help understanding a concept or working through a particularly thorny issue.
- Developer (Dev) - The heart and soul of the process, the developer actually writes the code that the Development Leads provided specifications for.
- Quality Assurance (QA) - The quality assurance role is an often thankless position that is designed to find bugs before they find their way to the end customers. Using a variety of techniques ranging from keying in data and playing with the system to formalized, automated testing scripts the Quality Assurance team is responsible for ensuring the quality of the solution and it's fit to the requirements gathered by the Functional Analyst. Sometimes the QA team is known by their less flattering name of testers.
- Deployment (Deploy) - The deployment role is the one which packages up all of the compiled code and configuration files and deploys it through the appropriate environments or on the appropriate systems. The deployment role is focused on getting the solution used. To that end the role may include automated software installation procedures or may be as simple as copying the files to the appropriate place and running them.
- Training - The training role is responsible for documentation for the system as well as any instructor or computer based training solutions, which are designed to help the users better understand how the system works and what they can do with it.
- Project Manager (PM) - The project manager is responsible for ensuring consistent reporting, risk mitigation, timeline, and cost control. The project manager role is a problem solver role. They try to resolve problems why they are small so that they can be handled more quickly and with less cost.
- Development Manager (DM) - The development manager is responsible for managing multiple priorities of conflicting projects. The Development Manager role is also an escalation for issues from the team, which it is unable to resolve internally.
Of course, each organization has it's own take on these roles; however, these are the roles you'll see most often in an organization doing development.
Over the course of the next few weeks, articles will be published that delve deeper into each of the above roles.
Critical Skills for Every Role
In the articles describing each role there is a section, much like this one, which is designed to support a bulleted list of items that are critical to the success of the role. During the creation of the series a common set of skills was identified that were essential business skills that professionals in nearly every role needed to consider during their career. Rather than repeat them within the individual articles describing each role, they have been brought together here so that you could consider the impact of these roles in whole no matter where you are in the software development process. The common skills to all roles are:
- Understanding Business - Although some roles are focused very specifically around certain aspects of understanding and converting business requirements, every role in the process should have an awareness and sensitivity to the business processes and needs which require technology in the first place. Without this technology may be implemented but it may not solve the real needs and will therefore be considered a failure.
- Broad Understanding - Although an understanding of software development is critical there are other areas where an understanding can be invaluable. For instance, understanding how computers work internally including memory, cache, hard drives, etc., can help you learn how to more appropriately conserve those resources. Similarly understanding networking can help in the development of applications, which are compatible or even friendly to the networks that they're working across. SMEs broad understanding of the industry can be invaluable in terms of creating solutions that fit both the organization and the industry. The QA team can benefit the project by a broad understanding by minimizing QA costs while improving testing coverage. In short, a broad understanding can help every role.
- Multiple Perspectives - The ability to approach solutions from multiple perspectives is critical to software development. Understanding how each person who is working on a problem views an issue - or how different customers will view the solution is important to be able to find the best solution based on all of the information. There are always multiple ways of viewing - and solving - a problem. The trick is to find the best one from the list of possible options. The larger the list of options (perspectives) the better the solution.
- People Skills - Also known as soft skills, the ability to interact with other people and to be a part of a team is essential to nearly every role in a software development project. The lower the overall people skills of the team the higher the likelihood that the project will end in some explosion.
- Lifelong Learning - Although some might argue that the perspective of being a life long learner is more of an attitude than a skill, it is a critical part of being in a high-change industry like IT in general and software development specifically. What is learned today will be obsolete tomorrow. The only way to stay ahead of the game is to approach life from the perspective of continuous learning. Each new experience is a new opportunity to learn and each new year brings with it the need for skills renewal.
In the next article, the first detailed review of a role in the series, we'll delve into the role of the SME in the process and what specific skills can make an SME stand out from the rest.
About the Author
Robert Bogue, MCSE (NT4/W2K), MCSA:Security, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. He was honored to become a Microsoft MVP for Microsoft Windows Server - Networking . You can reach Robert at Robert.Bogue@CroweChizek.com
Trackback: http://www.developer.com/print.php/3490871
- ~ Posted by Deepak Kamboj on October 8, 2009
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.
The term also refers to documentation of a system's software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects
Views
Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. Within the ontology established by ANSI/IEEE 1471-2000, views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns.
Some possible views (actually, viewpoints in the 1471 ontology) are:
- Functional/logic view
- Code/module view
- Development/structural view
- Concurrency/process/thread view
- Physical/deployment view
- User action/feedback view
- Data view
Examples of Architectural Styles / Patterns
There are many common ways of designing computer software modules and their communications, among them:
Different type of architectures
Activities such as software architecture, network architecture, database architecture may be seen as partial contributions to a solution architecture.
Enterprise Architecture
The term enterprise architecture refers to many things. Like architecture in general, it can refer to a description, a process or a profession.
To some, "enterprise architecture" refers either to the structure of a business, or the documents and diagrams that describe that structure. To others, "enterprise architecture" refers to the business methods that seek to understand and document that structure. A third use of "enterprise architecture" is a reference to a business team that uses EA methods to produce architectural descriptions of the structure of an enterprise.
A formal definition of the structure of an enterprise comes from the MIT Center for Information Systems Research:
Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
Enterprise Architecture describes enterprise applications and systems with their relationships to enterprise business goals.
Another comprehensive definition of enterprise architecture is provided by the IFEAD (Institute for Enterprise Architecture Developments) as:
Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.
Many enterprise architecture frameworks break down the practice of developing artifacts into four practice areas. This allows the enterprise to be described from four important viewpoints. By taking this approach, enterprise architects can assure their business stakeholders that they have provided sufficient information for effective decision making.
Enterprise Architecture Areas of Practice
These practice areas are
- Business:
- Strategy maps, goals, corporate policies, Operating Model
- Functional decompositions (e.g. IDEF0, SADT), capabilities and organizational models
- Business processes
- Organization cycles, periods and timing
- Suppliers of hardware, software, and services
- Information:
- Metadata - data that describes your enterprise data elements
- Data models: conceptual, logical, and physical
- Applications:
- Application software inventories and diagrams
- Interfaces between applications - that is: events, messages and data flows
- Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization
- Technology:
- Hardware, platforms, and hosting: servers, and where they are kept
- Local and wide area networks, Internet connectivity diagrams
- Operating System
- Infrastructure software: Application servers, DBMS
- Programming Languages, etc..
Solution Architecture
Solution Architecture in enterprise architecture is a kind of architecture domain, that aims to address specific problems and requirements, usually through the design of specific information systems or applications.
Solution architecture is either:
- Documentation describing the structure and behaviour of a solution to a problem, or
- A process for describing a solution and the work to deliver it.
The documentation is typically divided into a broad views, each known as an architecture domain.
Solution architecture is related to enterprise architecture. The solution described may be all or part of what an enterprise architect's migration plan delivers. The solution might be unrelated to any such plan. Solution architecture often leads to software architecture work and technical architecture work, and often contains elements of those.
A Solutions Architect is often but not always focused on technical architecture and the meeting of non-functional requirements, often in the context of deploying specific applications.
References: http://en.wikipedia.org/wiki/Software_architecture
- ~ Posted by Deepak Kamboj on October 7, 2009
Introduction
Traditional applications using relational data sources such as Oracle, SQL Server and DB2 to expose their business logic to external world in a tightly coupled manner. This tightly coupled approach leads to the performance\scalability issues. This post discusses the Designing a SOA enabled DAL with example.
Traditional Service Data Access
Above figure shows the set of web services accessing the same relational database. Every request from the client requires data access which creates the performance issue when multiple concurrent users are trying to access the database.
Traditional applications having their own databases and when we migrate to the SOA data integrity issues will arise.
SOA Model Data Access
SOA model represents the loosely coupled architecture where business logic and Data access logic are no longer integrated. We are using LINQ-SQL as an interface for the SOA DAL.
SOA DAL only exposes the DTO’s[Data Transfer Objects] to the services
DTO representing the Employee looks like the following
Data Transfer Objects
This DAL is a provider independent and can be pluggable to different databases by reading the provider from the configuration file.
The Data provider using LINQ to SQL looks as follows
Data Provider
The DataService that exposed through service layer looks like
Now You can call the above service in windows or web application. We have seen how we decoupled the application from data access logic.
More information on building the SOA data access at http://msdn.microsoft.com/en-gb/magazine/dd263098.aspx.
- ~ Posted by Deepak Kamboj on September 22, 2009
Introduction
This Article series helps the .NET developers and architects to design the effective applications on .NET latest technologies. There are so many articles,books on application architecture but it is still challenging for developers to understand best practices, principles for the application design.
This post speaks about the fundamentals concepts of Application Architecture and principles.
What is Application Architecture?
Defining a solution which meets all technical and operational requirements by optimizing performance,security and manageability.
Why Architecture?
Software must built on a solid considerations and failing to meet the key scenarios and understand the design problems will lead to long term consequences. The application needs to address the following concerns .
- How the end user be using your application?
- What about quality attributes security,performance,concurrency, internationalization and configuration.
- What architecture suits for your application now or after it has been deployed?
Goals of Architecture
Application Architecture builds the bridge between business requirements and technical requirements. Good architecture reduces the business risks associated with the solution.
Architecture should consider
- Structure of the system not the implementation details
- User case scenarios
- Concerns of stake holders
- functional and quality requirements
Approach to Architecture
You must determine the type of application that you are building and architecture styles that will be used and cross cutting technologies.
- Identify the type of application
- How the application will be deployed?
- Drill down for architecture styles and technologies
- Considering Quality attributes and cross=cutting concerns.
Application Type
Key part in architecture and design is identifying the type of application.
The application types can be
- Rich Client application designed to run on client PC.
- Rich Internet applications.
- SOA applications designed to support communication between loosely coupled components.
- Smart client applications.
Deployment Strategy
When you design your application you must plan the infrastructure to deploy your application. Your application must accommodate any restrictions that exist in the environment. Identify infrastructure architecture early in the design process.
Architectural Style
Architectural style is set of policies and rules that we used in the component design later that we use in the application.
Examples of architecture styles
- Client-server
- Layered architecture
- MVC
- SOA
Cross cutting concerns
These concerns are key areas in your design that are not related to any layer in your application. You must consider the following concerns when you are designing your application.
Authentication Determine how to authenticate users and pass the identities across the layers.
Authorization Ensure proper authorization across the trusted boundary.
Caching Identify what should be cached and where to cache to improve your application’s performance and responsiveness.
Communication Choose appropriate protocols to protect sensitive data passing over the network.
Exception Management Catch exceptions at the boundaries and show meaning full messages to the end users.
Instrumentation and Logging Instrument all business and system-critical events and log sufficient details. Do not log sensitive information.
Software Architecture can be described as structure of system, where system represents the collection of components that accomplish a set of functions. This post explains the key design principles for software architecture.
The above picture shows you the common application architecture and different components in the system and how they work together.
Design Principles
- Separation of Concerns Break your application into distinct features.
- Prefer composition over inheritance When reusing the functionality use composition over inheritance because inheritance increases the dependency between parent and child classes.
- Don’t Repeat Yourself(DRY) Define only one component for providing specific functionality and should not be duplicated in any other component.
Design Considerations
When designing a application, software architect is to minimize the complexity by separating the design into different areas. For example UI processing components should not include code that directly access a data source, instead it should use data access components to retrieve data.
Authentication
Failure to design a good authentication strategy can leave your application vulnerable to spoofing attacks and session hijacking.
Consider the following guidelines when designing the authentication strategy
- Identify your trust boundaries
- If you have multiple systems with in the application consider using the single sign-on strategy.
- Store the hash of the passwords in the database.
- Enforce the use of strong passwords.
Authorization
Consider the following guidelines when you are designing the authentication strategy
- Protect resources by applying authorization to callers based on their identity.
- Use resource-based authorization for system auditing.
Caching
Caching improves the performance and responsiveness of your application.
- You should use the cache for avoiding network round trips and avoid duplicate processing of data.
- Do not cache the volatile data.
- Do not cache the sensitive data unless you encrypt it.
Communication
It concerns the interaction between components across the layers. When crossing the physical boundaries, you should use message-based communication.
- Build the service interfaces for communication
- Consider using MSMQ to queue messages for later delivery.
Concurrency and Transactions
When designing for concurrency and transactions for accessing the database it is important to identify the concurrency data model that you want to use. The model can be optimistic or pessimistic.
- If you have business-critical operations, consider wrapping them in transactions.
- Use connection-based transactions when accessing a single-data source.
- Updates to shared data should be mutually exclusive, which is accomplished by applying locks.
- Avoid holding locks for longer period.
Configuration Management
- Encrypt sensitive information in configuration store.
- Provide separate administrative interface for editing configuration information.
- Categorize the configuration items into logical sections.
Data Access
Designing a Data Access Layer is important for application maintainability. The Data Access Layer should be responsible for managing connections and executing commands against data source.
- Avoid accessing database directly from other layers and should have the data access layer interaction for DB operations.
- Release the DB connections as early as possible.
Exception Management
Good Design of exception-management strategy is important for the reliability of your application.
- Do not catch the internal exceptions unless you can handle them.
- Design a appropriate exception propagation strategy.
- Design a strategy for unhandled exceptions.
- Design a appropriate logging and notification strategy.
Layering
Designing the layers allows you to separate the functionality into different areas of concern.
- Layers should represent the logical grouping of components.
- Components with in a layer should be cohesive means business layer components should provide options only related to application business logic.
Backtrack:
http://www.techbubbles.com/softwarearchitecture/application-architecture-for-net-applications-part2/