“Behind the Scenes” of the Enterprise Development Reference Architecture (EDRA) Jonathan Wanagel Microsoft patterns & practices

2 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

About This Talk  Things to Expect Polls Storytelling Questions Intermission

4 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

Microsoft patterns & practices  Guidance on Enterprise Business Applications  Available for download from Microsoft’s website  Learning the most significant challenges from customers  Analyzing the patterns and/or best practices for solving those challenges

6 Enterprise Development Reference Architecture (EDRA)  EDRA incorporates numerous best practices for solving enterprise business system challenges  Utilizes various p&p guidance to apply the best practices  Includes a reusable implementation of the architecture  Includes complete conceptual architecture documentation  Includes Global Bank sample application demonstrating real-world uses cases using the framework

EDRA Key Benefits  Extensible architecture for cross cutting concerns  Support for secure infrastructure deployments  Support for integration  Improved developer productivity  Easier adjustment to significant system requirement changes

Reference Architecture Challenges  Integration Capable  Multiple transport  Exception handling  Application hosting  Extensible architecture  Services Based  Stateless Components  Secure deployment  Transport choice  Developer Productivity  Developer Portability  Concern Separation  Live Configuration Updates  Requirements Change Adaptability (deployment, transport, etc)  Consistent Development Experience  Consistent Usage of Best Practices  Application Architectural Governance  Transaction Management  Authentication  Authorization  Validation  Remote Debugging  Compensating Transaction  Timeout Management  Instrumentation  Logging  Duplicate Requests (Idempotency)  Business Eventing

Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

Challenge: Integration Capable  Challenge Summary: An organization can have all the integration infrastructure in the world, such as various networks, EAI middleware, integration server products, messaging systems, etc. However, if an applications architecture is closed and offers no way of interfacing with any of the integration infrastructure, then you have an application that you cannot integrate with. How can you ensure your application architecture is integration capable so it is possible to be integrated with other systems?  Poll  Stories

Challenge: Integration Capable  More Challenge Details A new application may not start with integration requirements Sometime after deployment, integration requirements come up because of needs from other applications Want to avoid screen scraping or data oriented integration

Challenge: Integration Capable  Solution Best Practices Build your application with a cleanly separated business API Expose the business API with an external invocation mechanism Include an interception mechanism to allow adding hooks for raising “business events”  Questions

Challenge: Exception Management  Challenge Summary: All applications will have errors occur during operation, both expected and unexpected types of errors. When errors occur, how should they get handled by the application?  Poll  Stories

Challenge: Exception Management  More Challenge Details Do all errors get reported to the caller or user? What about error information containing information that is a security risk such as “Connection string X failed”? What about reporting errors to the system administrator? What about the error propagation within the system?

Challenge: Exception Management  Solution Best Practices Categorize errors as “business” errors versus “technical” errors Always propagate errors to the system boundary (unless explicitly handled) Use normal try/catch/throw, not error return codes Business logic code throws “business” errors such as a business rule violation, with a message that is safe and user appropriate At the system boundary, if error is a “technical” error then: Log the error for a system administrator including unique log id Replace error message with generic message to ensure unsafe information is not leaked Include log id in generic message for correlation  Questions

Challenge: Secure Deployment  Challenge Summary: A very common infrastructure setup for security is creating a perimeter network (DMZ) that “outsiders” access, separated with a firewall from the secure network. Additionally, there might be another firewall inside the secure network separating your database servers. How do you design your application architecture so it can be deployed to a secure infrastructure setup?  Poll  Stories

Challenge: Secure Deployment  More Challenge Details Are the “outsiders” users or systems (i.e. UI or programmatic access)? How do you split your application architecture for the different zones?

Challenge: Secure Deployment  Solution Best Practices Build your application with a cleanly separated business API Split your business tier into an “interface” and “implementation” Handle boundary verification responsibilities (validation, authentication, etc) in the interface Deploy your interface in the DMZ and implementation in the secure network  Questions

Challenge: Multiple Transports  Challenge Summary: Sometimes an application needs to be used by multiple external systems, but they do not all support a single communication mechanism. How do you design your application architecture so it can support multiple communication mechanisms?  Poll  Stories

Challenge: Multiple Transports  More Challenge Details The organization hasn’t implemented an integration server, or one or more systems are an “exception” to using it This application instance alone cannot justify bringing in an integration server, and expanding scope isn’t realistic Transitioning communication mechanisms and need to support old and new simultaneously, or plan to transition in the future

Challenge: Multiple Transports  Solution Best Practices Create a separation between the communication transport and the rest of the architecture Normalize the request input and request output mechanisms of the architecture and have the transports adapt to them  Questions

Challenge: Concern Separation  Challenge Summary: Your organization or development team contains a mix of more skilled developers or architects experienced in dealing with technical issues, and less skilled developers experienced in coding business logic and rules. How can you factor your application architecture so the coding for the technical issues is separated from the coding of the business logic?  Poll  Stories

Challenge: Concern Separation  More Challenge Details Ratio of highly skilled developers to less skilled developers can be very low Coding things such as instrumentation, logging, authentication, database connections, transactions, and authorization tend to be different types of thinking then business logic When business logic and technical code are intermingled, it makes it harder to follow the code when focusing specifically on the business logic or vice versa

Challenge: Concern Separation  Solution Best Practices Encapsulate the business logic into specific components called “business actions” Try to move as much technical code as possible into separate components from business logic For each business action, call the necessary technical components before and/or after the business action The components with the technical code can be further sub- divided based on concern type  Questions

25 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

Database Server Database Server Application Server Application Server Building An Architecture ASPX pages SQL Server Database Web Browser

Application Server Application Server Business Tier Business Tier Database Server Database Server ASPX pages SQL Server Database Web Browser Business Logic Business API

Application Server Application Server Business Tier Business Tier Database Server Database Server ASPX pages SQL Server Database Web Browser Business Logic Interception Mechanism ASMX pages Integration Infrastructure / External Applications Integration Infrastructure / External Applications Business Events Business API

Application Server Application Server Business Tier Business Tier Database Server Database Server ASPX pages SQL Server Database Web Browser Business Logic Interception Mechanism ASMX pages Integration Infrastructure / Other Applications Integration Infrastructure / Other Applications Business API Exception Management Business Events

Application Server (Secure) Application Server (Secure) Service Implementation Service Implementation Application Server (DMZ) Application Server (DMZ) Service Interface Service Interface Database Server Database Server ASPX pages SQL Server Database Web Browser ASMX pages Integration Infrastructure / Other Applications Integration Infrastructure / Other Applications Firewall Business API Business Logic Interception Mechanism Exception Management Boundary Logic Business Events

Application Server (Secure) Application Server (Secure) Service Implementation Service Implementation Application Server (DMZ) Application Server (DMZ) Service Interface Service Interface Database Server Database Server ASPX pages SQL Server Database Web Browser ASMX Integration Infrastructure / Other Applications Integration Infrastructure / Other Applications Firewall Business API InProc MSMQ Internal Application Internal Application Business Events Boundary Logic Business Logic Interception Mechanism Exception Management

Application Server (Secure) Application Server (Secure) Service Implementation Service Implementation Business Logic Business Logic Application Server (DMZ) Application Server (DMZ) Service Interface Service Interface Database Server Database Server ASPX pages SQL Server Database Web Browser ASMX Integration Infrastructure / Other Applications Integration Infrastructure / Other Applications Firewall Business API InProc MSMQ Internal Application Internal Application Business Events Concerns Biz Actions

33 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

Creating an Architectural Framework  Creating an architectural framework is taking an architecture and making it reusable  Some challenge best practices can help with reusability  An architectural framework is itself a best practice for solving many challenges

35 Challenge: Consistent Usage of Best Practices  Challenge Summary: Various architectural best practices may be known by different people, but the applications being built by the organization inconsistently apply them. How can you ensure that best practices are used as new applications are being developed by various development teams across the organization?

36 Challenge: Consistent Usage of Best Practices  More Challenge Details Organizations often make efforts to try and improve the quality of architectures across the company Setting up meetings or trainings to share “best practices” across projects or teams Creating documentation or training to show best practices that can be used  Why a Framework Helps Usage of best practices on an application can become an “implicit” activity requiring no training or communication Adding best practices to development can also be “implicit”

37 Challenge: Developer Productivity  Challenge Summary: The various business units in your organization always have more IT needs then what gets fulfilled because they cannot afford or justify the costs. How can you improve the productivity of the development teams to try and fulfill more business needs cost effectively?

38 Challenge: Developer Productivity  More Challenge Details More training Improved development processes More developer specialization  Why a Framework Helps Reduced time spent on establishing and building the architecture Reuse of architecture reduces overall development

39 Challenge: Application Architectural Governance  Challenge Summary: Many organizations have a person or group responsible for setting rules or policies affecting the architectures of applications. How can you enforce rules or policies that affect application architecture or development?

40 Challenge: Application Architectural Governance  More Challenge Details How to communicate rules and policies Enforcement through reviews and general policing What to do when application slips through the cracks How to keep existing applications compliant with rules and policies  Why a Framework Helps Rules and policies can be enforced through updates to framework Existing applications can be upgraded to newest framework to ensure compliance

41 Challenge: Developer Portability  Challenge Summary: Organizations often need to transfer developers from working on one application to another. This can mean significant ramp up time for the developer to understand the application well enough to work on it effectively. How can you reduce the ramp up time necessary for a developer to switch from working on one application to another?

42 Challenge: Developer Portability  More Challenge Details Sometimes moving developers occurs in “swaps” that take a long time because you then have ramp up dependencies Understanding an application architecture can be time consuming Understanding the business logic versus architecture logic  Why a Framework Helps A framework creates more consistencies in architecture requiring less ramp up time Better separation of concerns allows focusing more strictly on business logic

43 Challenge: Requirement Change Adaptability  Challenge Summary: Changes in the requirements for an application can usually be reasonably handled if they affect business rules or business functionality. But requirement changes that impact the architecture can be extremely difficult to deal with. How can you reduce the difficulty of dealing with requirement changes impacting an applications architecture?

44 Challenge: Requirement Change Adaptability  More Challenge Details Difficult to predict the requirement changes Cost of adding flexibility  Why a Framework Helps Reusability for different scenarios offers flexibility Flexibility cost is significantly less

45 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

To Download  To download the EDRA source code, documentation, candidate features for future releases, and the EDRI: Go to the EDRA community workspace at Sign in (you will first need to join the workspace) Go to the “Releases” section  For a knowledge base on EDRA including frequently asked questions, known issues, etc: Go to the Wiki site at

Summary  Application architecture requires understanding and choosing your challenges  Architectural frameworks can help solve challenges  EDRA is an application architectural framework that attempts to incorporate several best practices

48 Agenda  About This Talk  What is p&p and EDRA  Application Architecture Challenges  Building an Architecture  Creating an Architectural Framework  Summary  Questions

Questions?