Resuming our training for Aspiring Architects, here we got from MS India a third series, this time focused on the Messaging Infrastructure, its planning, constraints, scalability, etc
I want to thank Ramnish Singh (Infrastructure MCA in MS India) for this contribution, that I'm confident that will help a lot IT Pros raise the bar, start thinking on computing environments in a different manner and get the necessary background and skills
The remaining ingredients in the Architecture Career prescription is up to you, guys: experience, dedication and passion! 
Enjoy!
Introduction to Designing a Messaging Infrastructure
The Architecture Series is intended for those involved in planning, designing, and implementing an enterprise-class infrastructure project, including consultants, system architects, and IT professionals who are responsible for messaging infrastructure deployment. The series is aimed at empowering systems integrators and IT professionals with validated architectural guidance for Messaging. |
Designing and planning messaging services
This session will cover the first major design decisions when creating an Messaging infrastructure - Directory Services. The session will highlight recommend Active Directory configurations, server deployment based on best practices, budget, and other business factors, network topology and provide technical recommendations and discuss new Exchange 2007 features. |
Designing and planning high availability
This session will cover high availability solution based on client types and client loads. It will also cover design of policies to handle unsolicited e-mail and virus outbreaks, disaster recovery, backup, and restore solution. The presenter will also recommend a strategy for dependent services that impact high availability. |
Designing and planning coexistence and migration
This session will cover the plan for migration of messaging systems. The presenter will also discuss various migration and coexistence strategies. |
Defining policies and security procedures
This session will cover how to address regulatory and legal requirements. The presenter will also discuss message content filtering and how to design a secure messaging environment. |
Notes from Field and Contest Case Study
This session will showcase the best practices followed for Messaging Architecture and will have panel of experts discuss their Enterprise (Messaging) Architecture experiences. |
After the initial success of the original Aspiring Software Architects Program, there was a second series focused on Infrastructure Architecture, especially related to Identity and Group Management, network planning, availability and so on
The program was a complete success so I asked Ramnish Singh (Infrastructure MCA in MS India) for the chance of making all these available for any aspiring architect all over the world (session language is English in all cases). I want to thank Ramnish for this contribution, that I'm confident that will help a lot IT Pros raise the bar, start thinking on computing environments in a different manner and get the necessary background and skills
The remaining ingredients in the Architecture Career prescription is up to you, guys: experience, dedication and passion! Enjoy!
Introduction to Designing an Active Directory Infrastructure
The Architecture Series is intended for those involved in planning, designing, and implementing an enterprise-class infrastructure project, including consultants, system architects, and IT professionals who are responsible for directory services infrastructure development and deployment. The series is aimed at empowering systems integrators and IT professionals with validated architectural guidance for Active Directory. |
Designing a Forest and Domain Infrastructure
This session will cover the first major design decisions when creating an Active Directory infrastructure - Active Directory logical structure and the design of forests and domains. |
Designing a Site Infrastructure
This session explains how to design a site topology to organize the network in your organization and optimize the exchange of data and directory information. |
Designing the Administrative Structure
This session explains how to design administrative structure to delegate authority and simplify administrative overhead and design an organizational unit structure. |
Designing for Group Policy
This session describes how to gather and analyze business requirements and other data and then use that data to design a Group Policy structure and integrate the structure into an organizational unit design. It describes the role of Group Policy in the Active Directory infrastructure and factors in choosing particular implementations, such as security, software deployment, and administrative requirements. The session also covers why and how to design a change management structure. |
Designing the Physical Network
This session describes how to gather business requirements and other data and then analyze and use that data to design the physical network. It explains how to design a connectivity infrastructure, with considerations for intrasite and intersite connectivity, router placement, connection types, and virtual private networks (VPNs). |
Designing a Name Resolution Strategy
This session describes the relationship between Active Directory and DNS domain names, Windows Internet Name Service (WINS), and other name-resolution strategies. |
Designing the Network Access Infrastructure
This session describes how to design a network access infrastructure by gathering relevant data, and then analyzing and using that data to design for network access security, remote access, and wireless access. The module includes strategies for authentication, administration, access monitoring, interoperability, and user education. |
Designing for Federation
This session describes how to design Active Directory to support Federation. Active Directory Federation Services (ADFS), a next-generation information security infrastructure designed to help IT professionals extend internal applications to external users. |
Notes from Field and Contest Case Study
This session will showcase the best practices followed for Active Directory Architecture and will have panel of experts discuss their Enterprise (Active Directory) Architecture experiences. |
ASAP, Aspiring Software Architects Program, was a series of web casts originally delivered for aspiring application architects in India. It brought Champion Architects from Microsoft's partner organizations who were challenged by Microsoft host, Vikram Rajkondawar to share their experience, challenges faced, pitfalls and lessons learnt across interesting topics
The program was a complete success so I asked Vikram for the chance of making all these available for any aspiring architect all over the world (session language is English in all cases). I want to thank Vikram for this contribution, that I'm confident that will help a lot of developers raise the bar, start thinking on computer applications in a different manner and get the necessary background and skills
The remaining ingredients in the Architecture Career prescription is up to you, guys: experience, dedication and passion! Enjoy!
Architecture and Design Fundamentals in the .NET World
This session talks about architecture from the .NET perspective. We will try to understand the roles of architects and designers in a software project. We will delve into patterns and practices, some of the enterprise solution patterns authored by Microsoft. We will discuss software factories and debate the viability of software factories. We will discuss tools and offerings from Microsoft and also some open source tools that enable Continuous Integration. Towards the end we will discuss the Architecture of the Case Study. |
Abilities Design : Architecting for Performance
This session talks about how to architect and design applications for application performance with proven models. We will discuss various best practices used to architect, design and code applications that would help in providing consistent performance against industry benchmarks. We would also discuss various techniques to review, measure and tune performance. |
Architecting the UI Layer
This session we would discuss how to architect consistent, scalable and high user performance user interface. We would also look at the end user productivity gains that organization can expect from a great UI, using the various UI design patterns, web client software factories and leveraging web 2.0/Ajax in creating a extensible environment. |
Architecting End-to-End Security
This session focuses on the various security considerations that influence the development of the architecture of a .NET application. It starts with the business imperatives of considering security and the right amount of security to implement in the architecture. It also discusses security topics like authentication, authorization, auditing, single sign-on, external interface security, secure data transmission and storage as well as security architecture for SaaS scenario. It discusses the value of conducting threat modeling in application development and also the secure coding practices that must be implemented to mitigate the risks associated with the common attack vectors. |
Designing Service and Business Layer
This session discusses the best practices around building business layer as well as service layer components. It also focuses on the importance of moving towards SOA and terminologies and ontology relevant to service orientation. This session also discusses the patterns and anti-patterns which are appropriate for business and service layer design/development. We will also talk about Microsoft’s Web Services Software Factories implementations which are useful to get started on SOA along with the case study. |
Data Architecture
This session is about the guidelines for implementing a data tier in a multi-tier .NET based application. We discuss on what are the challenges faced during designing the data architecture and the considerations that an architect should take care of. We also discuss on different methods/patterns available for passing data across various layers and for e.g. how SaaS or SOA architectures influence these decisions. |
Testing for Architects
This session is about how testing influences architecture, and how it helps architecture. We discuss the various types of testing - functional testing, non-functional testing (load tests, stress tests, etc.) and touch upon performance testing - what counters to look for, what some interpretations are, etc. We also look at testing in the current RIA / SOA world. We also look at Microsoft's offerings in the testing arena, and how to leverage these tools well. |
Deployment and Management and Transitioning to an Architect
In this session we discuss on how Deployment Management directly impacts revenue and end customer satisfaction. We discuss the criticality to map system functional, non functional requirement to production physical environment in early stages and define deployment strategy. We will also talk about some of the key aspects to be considered while deployment like Management are Security Consideration, Rollback Process, Application Configuration Information, Error Logging Mechanism, System Alerts Management, Load Balancing and lot more. |
A new friend I got, J.D. Meier, is leading a project intended to provide renewed Architecture Guidance for the Microsoft platform, and specifically for .NET applications
J.D. was compiling input from different sources and launched a web site for his project in CodePlex (a Microsoft portal for community projects, most of them available with code, samples, screencasts and so on)
I had the privilege of being enlisted in J.D.' list an one of his inquiries was about my beliefs on exception handling. I had written a blog post three years ago about that although, ugh!, I did it in Spanish as I was living in South America at that time
I was about translating my blog post for J.D. but better than emailing my outcome, I considered worth making my ideas of public domain, so here we go:
There are four common antipatterns (those are, bad practices, bad habits) when dealing with exceptions in today's platforms like .NET and Java. Those are:
- Exaggerated "exceptionalization"
- Unnecessary intervention
- Negligent inaction
- Inopportune handling
Let's review each.
- Exaggerated "exceptionalization". I heard about several software projects where their management thought that exceptions were made to address any abnormal situation. All abnormal situations. That way, data entry modules validated received input and before the first mandatory field left blank, the first entered date field violating the "MM/DD/YYYY" mask, etc, an exception was thrown. Just because the policy was throwing an exception for each abnormal situation
That got the programming cost more expensive as all that plumbing of exception throwing & catching was developer responsibility. But that was just to start: the code became illegible as the treatment of these exceptions was several line of codes further. Occasionally, several entries in the callstack further
So we can say they got two undesired consequences: too much code and illegibility. A better approach in cases like these should have handled validations in situ, giving control back to the user when some field was entered wrongly, in a simple and direct manner (that is, without changing an error for another one)
- Unnecessary intervention. It's normal having code blocks that call modules that eventually throw exceptions. What I find anti natural -accepting that not everybody thinks as I do- is having to be prepared to react before any possible exception. I remember from my participation in a project at a multinational bank, that enclosing between a try - catch block every method call that could throw exception was imperative. And it was forbidden doing nothing inside the catch brackets. To prevent this, the project management staff asked certain development team members to build a robot that reviewed the project source code, hunting for empty catch's. After some while, the managers got finally convinced about the fact that not all the time there's something to do before an exception, but they just made their position a bit more flexible (and consequently, the robot), by allowing in such cases the chance of documenting inside the catch an explanation about why not to intervene. Since then, developers in a hurry to finish their part started entering explanations like /* dkjfhashakjbadshkjdkfjdhkj */ in empty catch's, and the robot has never found a violation of the rule again
The real thing behind this story is that, in any code segment, there will be exceptions thrown by module invocations which sometimes we could handle, so we could act in consequence, sometimes our involvement will be simply senseless. An example of this? The Data Access Layer (DAL) returns System.Data.SqlClient.SqlException because the connection string was sent with an expired password. The exception is caught in the Business Layer, the one that called the DAL. Does it make sense catching the exception in that place? Maybe to make the answer more obvious, the question could have been "can the Business Layer create a new password for the DAL?"
The right thing in that case is masking, before leaving the DAL, the low-level exception (coupled to ADO.NET in this case) as a high level one without losing the original exception as it's the one that holds the stack-trace). The original exception is usually known as root cause and logged, while the high-level exception is shown to the user. For more info, let's check next
- Negligent inaction. This is the opposite scenario regarding the previous case, also negative. It happens each time we leave go any occurred exception without taking over not even to mask certain error messages in order to avoid slapping users faces with low-level explanations like the expired password when trying to connect to the database
Eluding any intervention, as a policy, leads to code with unpredictable behavior. That erodes its reliability from a development perspective, and its usability, from the users perspective
However, how to set the correct degree of involvement without falling in the previous anti-pattern? As told before, masking the low-level exception into a higher one before leaving the layer or module where that exception is produced. Special care here, as I previously said, of original exception nesting as the new exception will be useful for presentation purposes (thinking in the user), while the original one will allow to understand what provoked it (when IT responsible personnel takes over) and the first measure in order to prevent these situations in the future, mostly if the cause is a software bug (the example of the expired database password does not belong to that category). Don't you remember having seen a web site where, after clicking in some submit button, you got a beautiful message in red characters, like [ODBC Exception, SQL code = ...]? Wouldn't have been better logging that error while communicating to the user something like "We are experiencing some difficulties. Please try again later or call to our operators at (XXX)XXX-XXXX"
- Inopportune handling. A customer of mine reclaimed about the low reliability of MS .NET regarding exception handling. He told me that they, before certain range of exceptions, had a handler invoked in the catch section. The handler generated a record in a database with the exception, with the end of taking monthly statistics on their software failures. Concretely, his recrimination towards .NET was that, while was generating the record in the database (low-level speaking, acting in a transaction-oriented manner with locking mechanisms, etc) the web user stayed waiting as a silly for an answer that, worst of worst, was abnormal
When checking deeper, we found that the catch logic was executed by design in the same thread where the exception had been occurred. Therefore, if we are urged to let the user know that we couldn't, but we also want to generate a record for stats that are reviewed in a monthly basis, the advice here is perform simple logging (a plain text file, not even XML), loading the database in offline using, for instance, ETL mechanisms
Even, if stats may be checked anytime and we want to have information updated, let's say, 10 minutes ago or even less, we can forget ETL by applying fire-and-forget mechanisms in the exception handler. For instance, the exception handler can post a message to a queue whose consumer -necessarily another thread or process- will complete the action by registering it into a database. Thus, the handler just post to the queue and returns the control to its invoking catch, which in turns will finish and return error and control to the user. The persistence logic stays, that way, decoupled and will be executed asynchronously
I want to invite anyone to share experiences to J.D., anti-patterns and their respective best practices in exception handling
PS. An interesting study on Exception Handling is found in Rod Johnson's best seller "Expert one-on-one: J2EE Design and Development" (Wrox, 2003, pages 125-132). I strongly recommend its reading
.jpg)
Two years ago, when an article of mine about evolving architectures was published in an independent IT magazine, a colleague said to me, “You should write for The Architecture Journal.” I couldn’t have predicted that I would now find myself writing for this magazine as its editor. I want to thank Simon Guest for this opportunity and these big shoes to fill; during his tenure, readership has more than doubled, increasing from 30,000 to 62,000+.
In this issue, we invite you to think about the identity architecture in your organization. Identity management today is evolving from the single, isolated scenario to a federated one, in ways that might surprise you.
We begin this sixteenth journey with Fernando Gebara Filho’s introduction to identity concepts and strategies, how they have evolved and the road ahead. Next, Jesus Rodriguez and Joe Klug examine an assortment of strategies for making identity a first-class citizen in the portfolio of federated applications. Gerrit van der Geest and Carmen de Ruijter Korver consider the challenge of establishing an application-level trust environment, as user identities, in a service-oriented world, must flow from a service consumer to a provider.
For this issue’s profile, we caught up with Kim Cameron, author of “The Laws of Identity,” whose ideas on federated identities are shaping the next generation of Microsoft identity technologies. (A funny thing happened the day I visited Kim for this interview: I forgot my ID badge, so I needed Kim to “certify” my identity to the lobby.)
Resuming our journey, Mario Szpuszta describes how the Austrian healthcare system turned an administrative provisioning crisis into a clear opportunity for creating an open identity federation. Then Vittorio Bertocci explains how architectural patterns allow us to build claim-aware solutions, so that when the cloud arrives to companies, identity management won’t necessarily look cloudy.
Finally, Mike Morley and Barry Lawrence reveal how they synchronized identities on multiple systems and legacy applications from a single administrative console through a consolidating framework.
Dear reader, I’d like to be the first to welcome you to the issue, and hope that you’ll identify with the articles within. Enjoy!
Bonus article:
David Chou offers a comprehensive view of strong user authentication by examining its concepts, implementation approaches, and challenges and additional concerns
The 18th issue of The Architecture Journal will be focused on Green Computing. The ubiquity of technology services is leading to significant energy waste, in a world where increasing energy costs and the need to reduce carbon footprints are becoming an imperative.
We are looking for practitioner experiences and ideas on sustainable IT environments and solutions, addressing issues such as the following:
- What are, beyond theory, the actual green technology big bets?
- What considerations must be taken when building a physical data-center?
- How do environmental regulations impact architectural decisions?
- What could you say about Green Business Intelligence? Do you have some pattern for collecting, managing, and enacting environmental data? What are the best BI and data practices for analyzing environmental metrics?
- From a solution architecture perspective, what are the best practices for reducing environmental impact on business, employees, partners, and customers?
- Last but not least, are we ready to talk about green application development best practices? Do you know real strategies, patterns to use fewer resources and improve efficiency?
If you have opinions that you would like to share with the architect community on sustainable architectures, here is your chance! Follow the instructions below to send an abstract before the cut-off date and you could see your thoughts and ideas shared with over 62,000 readers, translated in 5 languages, and distributed at multiple conferences around the world!
The cut-off date for abstracts for the next issue is September 10th 2008. If you are interested in making a submission, here are the details:
How do I make a submission?
To submit an idea for a paper, please send the following:
- A 2 – 4 paragraph abstract explaining how your paper fits the "Green Computing" theme of the magazine
- A 1 – 2 paragraph bio
- A list of previously published articles
Submissions should be made via Email to editors@architecturejournal.net
We receive many submissions for each issue, so we encourage you to put time and thought into the submission.
When will I know whether my submission is accepted?
After the call for papers has ended, you will be notified via Email as to whether your submission was successful or not.
What happens if my submission is accepted?
If accepted, you’ll have between 6 weeks to submit two drafts and a final version of your paper. These dates will be clearly communicated. Your first draft will be reviewed by an editorial board to ensure it is on message for the magazine. Your second draft and final version will be subject to both technical and copy editing.
The magazine is generally available in print and online 4 weeks after final drafts are submitted.
What are the guidelines for papers printed in the Architecture Journal?
We recommend that papers are between 3,500 and 4,500 words in length – although we have accepted shorter and longer papers in the past. The article should be submitted using Microsoft Word. Diagrams should be submitted in either Microsoft Visio or Microsoft PowerPoint, and will be reformatted for the magazine.
Do I still own the work?
Yes. We ask you to sign a release form that gives Microsoft permission to reprint the article, but ownership of the paper remains with you, the author.
Will I get paid for writing?
We do not currently reimburse authors for contributing to the Architecture Journal.
Will I get copies of the magazine as an author?
After printing you’ll be sent 10 copies of the Journal for your own use. Additional copies can be requested.
Where can I get more information?
Check out this link
The next issue of the Architecture Journal will focus on Distributed Computing. We are approaching an inflection point with today’s hardware and technologies where a vision from only a few years ago is becoming reality –from deploying applications on microscopic devices in our environment through to football-sized datacenters offering applications in the cloud. Whether small or large, distribution and concurrency of multiple services can introduce a number of challenges – the focus of this issue is to understand what these challenges are, and how they can be overcome.
If you have opinions that you would like to share with the architect community on distributed computing, here is your chance! Follow the instructions below to send an abstract before the cut-off date and you could see your thoughts and ideas shared with over 60,000 readers, translated in 5 languages, and distributed at multiple conferences around the world!
The cut-off date for abstracts for the next issue is July 28th 2008. If you are interested in making a submission, here are the details:
How do I make a submission?
To submit an idea for a paper, please send the following:
- A 2 – 4 paragraph abstract explaining how your paper fits the "Distributed Computing" theme of the magazine
- A 1 – 2 paragraph bio
- A list of previously published articles
Submissions should be made via Email to editors@architecturejournal.net
We receive many submissions for each issue, so we encourage you to put time and thought into the submission.
When will I know whether my submission is accepted?
After the call for papers has ended, you will be notified via Email as to whether your submission was successful or not.
What happens if my submission is accepted?
If accepted, you’ll have between 6 weeks to submit two drafts and a final version of your paper. These dates will be clearly communicated. Your first draft will be reviewed by an editorial board to ensure it is on message for the magazine. Your second draft and final version will be subject to both technical and copy editing.
The magazine is generally available in print and online 4 weeks after final drafts are submitted.
What are the guidelines for papers printed in the Architecture Journal?
We recommend that papers are between 3,500 and 4,500 words in length – although we have accepted shorter and longer papers in the past. The article should be submitted using Microsoft Word. Diagrams should be submitted in either Microsoft Visio or Microsoft PowerPoint, and will be reformatted for the magazine.
Do I still own the work?
Yes. We ask you to sign a release form that gives Microsoft permission to reprint the article, but ownership of the paper remains with you, the author.
Will I get paid for writing?
We do not currently reimburse authors for contributing to the Architecture Journal.
Will I get copies of the magazine as an author?
After printing you’ll be sent 10 copies of the Journal for your own use. Additional copies can be requested.
Where can I get more information?
Check out this link
“Premature optimization is the root of all evil.”
-Sir Charles Antony Richard Hoare, a British computer scientist, later paraphrased by Donald Knuth in his book The Art of Computer Programming
Days ago, watching a documentary about the life of South American movie director Fabián Bielinsky, I paid particular attention to a thought he shared during an interview. He said that, when filming scenes, it usually happens that a given scene isn’t taped as the director originally assumed it would be. Sometimes that scene is reworked until the director gets what was originally wanted, while in some other occasions it’s just left the way it came, as it’s considered exponentially better than the initial sketch. So he concluded that the real art of making movies is deciding wisely when to do it again and when to just take what was gotten the first time around
Surprisingly, if that is the case for making movies, coding components is very similar to taping scenes. It’s always possible to get better approaches for a given algorithm. So, with the manager hat in our heads, we must decide when to freeze an always possible improvement for the sake of the timeline, budget, delivery due dates and general customer satisfaction, and when to go on and get more
So here is where we address the need for refactoring: a series of techniques and mechanisms to improve the quality -understandability, maintainability, modularity, extensibility, and so on- of code segments by reformulating their sentences in such a way that the general behavior remains unchanged. In other words, the behavior of the affected components shouldn’t vary as a consequence of the process but their quality, and hopefully, their longevity, should be increased
(The paragraphs above were extracted from the foreword I wrote for this Wrox book)
From Macedonia to Chile, from Chile to the World, Danijel Arsenovski (or simply Daneeha, as I claim having re-baptized the friend I met at the end of 2002 during a multinational Java project) reaches an important milestone in his career as Refactoring evangelist with this published book. In South America and particularly in Chile, lots of professional developers and architects first met the Refactoring concept thanks to the incipient talks Daneeha delivered for both Java and Visual Basic crowds
He also decisively participated in a major refactoring project for the bank we first met, rescuing the Corporate Financial Terminal (or TFC, such the project acronym in Spanish, the language spoken there, which Daneeha learned when immigrating from the Balkans) from being dropped and replaced by an upcoming new system due to the evident costs of maintenance TFC had. Daneeha wasn't alone and it wouldn't be justice to avoid mentioning Angel Valdés, Juan Barrera, Jorge Chávez and some other key players. The important thing is how the bank maximized the ROI of this project, turning a low-voice admitted failure into a source of revenue to be proud of
Daneeha comes back to tell you how to do the same. For profit and warranted fun. Why not
So we are just one month apart from the next edition of TechEd North America, to be performed at the Orange County Convention Center in Orlando (Florida, USA). This time, beside the typical topics on Architecture we wanted to stare also the architect role (something that it's often not considered but that sometimes is the key of success on any technical solution, design diagram or framework we decide to apply). So let's review the list of speakers and their topics to get a better idea of the ARC track value this season
In speaker first name alphabetical order...
|
Barry Gervin
|
Building Next Generation Data Access Layers with the ADO.NET Entity Framework |
As Developers, we've been building components in our data access layer (DAL) with ADO.NET classes such as Connections, Commands, DataReaders, DataSets and our own custom Helper classes and Data Classes. We build data access layers with a clear separation of concerns between business logic, data access, and data storage. We do this to increase cohesion and maintainability of our code, and also to increase developer productivity. What does this exactly mean in terms of the Entity Framework? What is the best approach to using the Entity Framework within our Data Access Layer? There are several workable models for leveraging the Entity Definition Model (EDM) within our applications. On one end of the spectrum, we can use the Entity Definition Model as a tactical tool for data access which is isolated to our Data Access Layer. This hides the Entity Framework from the rest of our application, effectively separating the concern of data access from the rest of our application. Another technique includes leveraging the conceptual Entity Definition Model deeply throughout our solution's layers and tiers. In this session, we compare and contrast these approaches including the middle ground, and see how these architectural choices affect maintainability, readability, and developer productivity. Most developers don't frequently have the opportunity to start from a fresh slate, so we'll also examine a refactored evolution from traditional data access layers through to incremental use of the Entity Definition Model. |
|
Brian Noyes
|
User Experience (UX): Selecting the Right Client Technology |
Choosing between Web and Windows applications has always been a challenging decision and often becomes a raging debate on every project where both are an option. Now you have to pick between multiple variants of each. Should you develop a smart client or a browser-based solution? Should you use Windows Forms or Windows Presentation Foundation for smart clients? Should you use straight ASP.NET, ASP.NET AJAX, XAML Browser Applications, or Microsoft Silverlight for browser-based apps? This session explores the motivations behind selecting smart client or browser-based applications and what key factors should steer you towards one or the other. It then demystifies the differences between the various options within each space and helps you understand when each one is appropriate. See sample implementations in each to get a feel for what is different about them from a development perspective, so you can factor in both your requirements and your development team's skills to the selection decision. |
|
David Chappell
|
Understanding Software-Plus-Services: A Perspective |
The move to service orientation is well underway, both inside enterprises and on the Internet. What role does traditional software play in a world of online services? In particular, how is Microsoft approaching the combination of software-plus-services? This presentation provides an overview of this area, giving an introduction to and a perspective on this emerging combination. A primary focus of the session is platforms for supporting hosted applications, i.e., applications that run in the cloud. |
|
David Chappell
|
Choosing Communication Styles: SOAP/WS-* vs. REST |
Two approaches to creating Web services are most visible today. One, using SOAP and the WS-* specifications, follows in the footsteps of earlier distributed computing technologies. The other, the RESTful style, is explicitly based on the principles of the Web itself. Both have value, and going forward, both will certainly be used. This presentation describes these two approaches, looks at when each one makes sense, and shows how Windows Communication Foundation (WCF) can support applications built using either style. |
|
David Platt
|
Why Software Sucks |
Users think that today's software sucks. It's unsafe, unreliable, and hard to use. These problems are not technical. We've been able to solve them for many years, but instead we've gotten a paper clip with eyebrows. Why? Software sucks because developers forget (or never knew) THE bedrock principle of software development: KNOW THY USER, FOR HE IS NOT THEE. For example, what do your customers come to you for? Hint: it's not software. For another example, do you think your users care about your application? They don't. Never have, never will. They care about accomplishing the task that it does. They don't want to think about you or your application at all. It's your job to care about them anyway. This session shows good and bad examples from commercial software and Web sites --those that understand and help their users, and those that treat users with contempt. For example, consider the ads for Microsoft Office that show non-upgrading users wearing plastic dinosaur heads. Developers fear looking like dinosaurs by not having the latest technology, but ordinary users fear breaking an installation that currently works, or having useless junk like dancing paper clips slow down their computers so they need to buy new ones. Your user is not you. We put this nation on wheels not by training the entire population as mechanics, but by improving cars so they seldom need mechanics. The same transition needs to happen to the software industry. This talk provides sound design principles so that your software won't suck. Learn how blindness will improve your vision. |
|
David Platt
|
Discussing Proven Practices for Using Smart Client Software Factory |
The Smart Client Software Factory is extremely valuable guidance released by the Patterns & Practices Team. Using the software factories enables us to solve common challenges that we encounter on a daily basis. At the same time using factories brings with it a significant learning investment. They are not always easy to understand, nor is it obvious which of the many paths to take (or not to take). In this interactive session, discuss patterns and anti-patterns of using the Smart Client Software Factory, and learn about the current state, philosophy, and goals of the new Windows Presentation Foundation Composite architecture. |
|
Jeffrey Palermo
|
Data Access Layer: Architectural Concerns for Object/Relational Mappers (O/R-M) with Examples in NHibernate |
O/R Mappers have crossed the chasm and are now mainstream. NHibernate is one of the primary ones in use today, and over the next few years, we'll see experience reports from LINQ to SQL and Entity Framework. This session explores some architectural decisions that face designers of systems using OR Mappers for data access. It discusses how to leverage the full power of the ORM while keeping the mapper decoupled from the application logic. Heavy emphasis is placed on testability and designing for maintainability. This session has a strong emphasis on separation of concerns and demonstrates how to provide for easy testing of the data layer while defining the architecture. All samples and demos are applicable to most OR Mappers but are demonstrated with NHibernate. |
|
Jeffrey Palermo
|
Architectural Considerations for the ASP.NET MVC Framework |
Microsoft is releasing the ASP.NET MVC Framework very soon, and many developers will begin using it right away. This session focuses on architectural concerns when using the MVC Framework. Dependency Injection can help decouple the application and make your code more maintainable and testable, but how do you enable this? Join Jeffrey Palermo for a boots-on-the-ground talk about how to fit ASP.NET MVC into your Web application architecture while avoiding some of the pitfalls common with Web Forms. We cover the following in depth: Designing for testability, loose coupling, separation of concerns, automated testing of controller actions, dependency injection, and leveraging IoC container support from the MvcContrib open source project. |
|
Juval Löwy
|
Software Development Life Cycle: Applying Service Orientation to the Development Process |
When you develop a service-oriented application, it would be naive of you to expect that the only things you will do differently will be limited to design and technology. The development process itself needs to be service-oriented. You cannot "stare into the fire" of Windows Communication Foundation (WCF) without a mature service-oriented development process supporting your effort. This talk presents you with a service-oriented development process that you can apply to your WCF-based products to plan and track your progress, manage requirements, and ensure faster time to market. |
|
Juval Löwy
|
Decoupling Contract from Implementation: Microsoft .NET Interface-Based Programming End-to-End |
Separation of interface from implementation is a core principle of component-oriented programming. The client is coded against an abstraction of a service (the interface), not a particular implementation of it (the object). This session starts by presenting .NET interfaces and describing various interface-based programming techniques. Next, see how to address a set of practical issues involving the definition and use of interfaces, such as Generics and interfaces, how to implement multiple interfaces, or how to combine interfaces and class hierarchies. The session ends with a discussion of interface design and factoring guidelines, and points out the best practices. |
|
Krzysztof Cwalina
|
Evolving Reusable Libraries: Microsoft .NET Framework Base Class Libraries, Lessons Learned |
Subsequent versions of reusable libraries need to be highly compatible. Because of that, such libraries are very difficult to change (evolve) after their initial release. This talk covers guidelines and techniques for designing and architecting reusable libraries so that they are easier to evolve. |
|
Mario Cardinal
|
Separation of Concerns: New Practices for Decreasing Coupling and Raising Cohesion |
This presentation presents simple but well-proven design principles to simplify managing dependencies between elements composing a .NET program. It discusses abstract class and interface as a means to reduce dependency surface; as well as component, namespace, and service as a means to decrease coupling. Learn the single responsibility principle, as well as dependency injection and inversion of control techniques to depend upon stability. At the end of this presentation you will understand why architects worry so much about coupling, cohesion, and separation of concerns. |
|
Mark Miller
|
The Science Behind Creating a Great User Experience |
Explore the how and why of great UI. If you believe you're not an artist, that UI is merely subjective, or that a great UI is not worth the effort, then this session is for you. Learn how to measure UI quality, covering user models, entry points, orienteering and discoverability, with tips and code samples for the Windows Presentation Foundation (WPF) and .NET developer sprinkled throughout. Regardless of whether you're building WPF applications or the traditional WinForms or Web ones, you'll learn how to reduce visual noise, lower barriers to entry, enhance clarity and in general make your applications a pleasure to use. It's all about making your customers happy, and this session shows you how. |
|
Miguel Castro
|
Using Sexy Extensibility Patterns to Build Long-Lived, Highly Reusable Applications |
Like everything else in the software lifecycle, some things are cool and some are just plain boring (though necessary). This session keeps you energized by showing you some exciting patterns that will allow you to enhance and extend an application without affecting the original design or code. Learn to design your applications using providers, plug-ins, and modules; in the end making an application as robust and full-flavored as a good beer. |
|
Miha Kralj
|
Architectures: The Good, the Bad, and the Ugly |
This session is designed to help architects develop critical thinking skills around the process and tools they use to develop their architectures. This will be accomplished by taking examples of failed architectures and mapping them to the patterns that could have been leveraged to improve the delivery. |
|
Pat Helland
|
Life beyond Distributed Transactions: An Apostate's Opinion |
Many decades of work have been invested in the area of distributed transactions including protocols such as Two-Phase Commit, Paxos, and various approaches to quorum. These protocols provide the application programmer a façade of global serializability. The presenter of this session is a strong advocate for the implementation and use of platforms providing guarantees of global serializability. In general, application developers simply do not implement large, scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. Natural selection kicks in, and instead, applications are built using different techniques which do not provide the same transactional guarantees but still meet the needs of their businesses. This talk explores and names some of the practical approaches used in the implementations of large-scale, mission-critical applications in a world that rejects distributed transactions. We discuss the management of fine-grained pieces of application data, which may be repartitioned over time as the application grows. We also discuss the design patterns used in sending messages between these repartitionable pieces of data. The talk is intended to provoke a different way of thinking about the direction of applications in a wildly scalable world. |
|
Pat Helland
|
The Irresistible Forces Meet the Moveable Objects |
There is a vast array of economic forces being unleashed on our industry today that require us to change how we create applications. From many core processors, low-end datacenters through to the rise of "Pervasive Intermittent Connectivity" and the re-definition of the Client, this session provides a unique perspective of the changing landscape and asks the question: How we can create applications that are approachable to implementers, composeable in their deployments, and responsive to these economic and technical forces bearing down on us? This talk is about a vision and not about product announcements. Be inspired by the future and join us! |
|
Paul Nielsen
|
Pragmatic Data Architectures: Six Measurable Attributes |
This session unpacks the Data Architecture Principle into the six measurable attributes of a data-centric application: Data Integrity, Performance/Scalability, Usability, Extensibility, Security, and Availability; and discusses the benefits and lifecycle costs of each attribute. Based on the premise that it's possible to achieve a balance of all six attributes though the pragmatic application of principle-driven data architecture, the specific tasks and design patterns that result in each attribute are presented as they relate to each of the five database-related roles (data architect, data modeler, database developer, database administrator, and data quality analyst) that contribute to the six properties. |
|
Rafal Lukawiecki
|
Data Protection with Cryptography of Microsoft .NET Framework 3.5 and CryptoAPI: Next Generation |
Are you still using DES, RSA, MD5 or SHA-1? Do you know how this might expose your company to a loss? Why is CAPI 1.0 being retired? Is the architecture of the new Open Cryptographic API for Windows (CNG, Cryptography Next Generation) any better than CAPI 2? What is Suite-B? Do you realize that the next few years will see a dramatic replacement of those security fundamentals we used to silently rely on? These are some of the questions we answer in this information-packed and fast-paced level 300 session aimed towards developers and architects who are already familiar with basic cryptographic and security concepts. We spend a good amount of time discussing the most recent crypto extension of .NET Framework 3.5: System.Security.Cryptography which has just been enhanced to give you direct access to the power of Suite-B, leaving CNG as your alternative, Win32 API. We explain when one API has advantages over the other, as you already would know which is easier to use. While we are not going to explain the inner workings of any of the covered algorithms, we do give you a good background to all the new ones, so that you can make better choices while designing Data Protection strategies for your systems. Windows Vista and now Windows Server 2008 have been the first commercial operating systems to include a full support for all of those innovations. Consider this as an opportunity to incorporate the awesome power of the recent security and cryptography developments in your software. For the curious, we may even tell you why we cannot tell you about Suite-A... |
|
Rockford Lhotka
|
Architects: How Are They Made? |
In a company where I worked we lost an employee with six months total experience because we wouldn't promote him to "Architect". Another company hired him in that role a week later. Is it possible to be an architect with six months' experience? Six years? What is it that makes some people valuable architects after just a few years, while others never even come close? Is it possible to cultivate architects? Train them? Or do they just spontaneously "get it"? Nearly every organization is crying out for quality architects at the enterprise, application, and systems levels. Come join in this nature vs. nurture debate. Learn what personal attributes you should look for or cultivate in prospective architects. Learn some techniques that do (and don't) work, information that will directly apply to your organization as you try to hire or create your own architects. |
|
Roy Osherove
|
Designing for Testability: Bridging the Gap between Design and Testing in Object-Oriented Software |
Unit Testing and Agile Methodologies seem to be the latest buzz in the software industry these days, but many people who actually try to Unit Test their application (whether new code or 'legacy' code) find out quickly that doing a thorough job can be tough if some thought about the code's design for testability is not considered. In this talk we discuss various methods of designing your APIs so that they are easy to test: Breaking dependencies with Dependency Injection patterns, how design patterns help, interface-based programming, and more. We also take a look at the future of testing tools and see what other options there are, or will be available as we architect our software with the next generation testing tools. |
|
Ted Neward
|
Pragmatic Architecture: The Role of an Architect |
Much has been said over the past half-decade about architects, their job, and their role(s) within agile development groups. Unfortunately, not all of it has been positive, leaving many practicing architects wondering what, exactly, they're supposed to be doing besides taking up space and acting as the scapegoat for project failures. In this presentation based on the MSDN columns of the same name, we take a hard look at the architect, his responsibilities, direction, and day-to-day duties. We explore this through a series of use-case project team scenarios, both agile and otherwise, and in the end, finally answer the question once and for all, "Is there room in the world for an architect on an agile team?" |
|
Udi Dahan
|
Web Scalability via Asynchronous Systems Architecture |
The main lesson learned from the big sites over the past year has been to step away from the database and do more work in memory. The scalability benefits of asynchronous communication have become better known, but many developers are still struggling with taking traditionally synchronous processes like user authentication and making them asynchronous. In this presentation, learn step-by-step the patterns, frameworks, and code needed to implement all user management processes for a Web site. The session deals with scalability, Web farms, sagas for long-running transactions, as well as the security implications of our decisions. | |
We just released the latest Journal issue, which you may read online here, subscribe, or even access when you are not connected, via the Journal Reader
This issue in particular is devoted to the fact of being architects and what that implicates, role responsibilities, accountabilities, skills, etc. We selected an assortment of articles from the outstanding answer that our call for paper received (what? didn't you know that we regularly set a call for papers? Don't miss the next one, so)
But it does not end there: your may also ask your questions around the role (based on your own day by day), or share your experience playing this role to your colleagues. In order to do so, we just launched an Architect Role "ad hoc" forum on MSDN
Looking forward to seeing you there!! 
.jpg)
The next issue of the Architecture Journal will be focused on Identity Architectures. As more organizations embrace a services based infrastructure, the need to manage the identities of users in an organization becomes more and more important. Issues that have been easy to manage in traditional environments need now to be considered from the perspective of services moving to the “cloud”.
This can include fundamental issues that you may even be facing now, such as internal authorization strategies; not only for employees, but how do you include partners and customers? More complex issues may include tiered access; what data is relevant to each user or user group? How do you secure that data? Is all identity data relevant in any circumstance or does it depend on the role of the user at any given time? How do directories compare to claims based authentication? What happens with multipart, distributed transactions? What about auditing in various contexts?
If you have opinions that you would like to share with the architect community on identity management, here is your chance! Follow the instructions below to send an abstract before the cut-off date and you could see your thoughts and ideas shared with over 60,000 readers, translated in 5 languages, and distributed at multiple conferences around the world!
The cut-off date for abstracts for the next issue is April 21st 2008. If you are interested in making a submission, here are the details:
How do I make a submission?
To submit an idea for a paper, please send the following:
- A 2 – 4 paragraph abstract explaining how your paper fits the "Identity Architectures" theme of the magazine
- A 1 – 2 paragraph bio
- A list of previously published articles
Submissions should be made via Email to editors@architecturejournal.net
We receive many submissions for each issue, so we encourage you to put time and thought into the submission.
When will I know whether my submission is accepted?
After the call for papers has ended, you will be notified via Email as to whether your submission was successful or not.
What happens if my submission is accepted?
If accepted, you’ll have between 6 weeks to submit two drafts and a final version of your paper. These dates will be clearly communicated. Your first draft will be reviewed by an editorial board to ensure it is on message for the magazine. Your second draft and final version will be subject to both technical and copy editing.
The magazine is generally available in print and online 4 weeks after final drafts are submitted.
What are the guidelines for papers printed in the Architecture Journal?
We recommend that papers are between 3,500 and 4,500 words in length – although we have accepted shorter and longer papers in the past. The article should be submitted using Microsoft Word. Diagrams should be submitted in either Microsoft Visio or Microsoft PowerPoint, and will be reformatted for the magazine.
Do I still own the work?
Yes. We ask you to sign a release form that gives Microsoft permission to reprint the article, but ownership of the paper remains with you, the author.
Will I get paid for writing?
We do not currently reimburse authors for contributing to the Architecture Journal.
Will I get copies of the magazine as an author?
After printing you’ll be sent 10 copies of the Journal for your own use. Additional copies can be requested.
Where can I get more information?
Check out this link.
Several debates on architecture overlap. At a first glance they could be treated as a whole, isolated from the rest, but when we go deep on them we discover that they are actually part of a major discussion
Endless struggles for high cohesion, low coupling, reasonable reusability or complexity reduction -just to mention some-, they actually want to conquer a same land: inexpensive development and later maintenance. A predictable, under budget, Software Development Life Cycle (SDLC)
However, those battles have given place to several strategies along the last decades: from the, nowadays old fashioned, Remote Procedure Call (RPC) to the updated Service-Orientation (SO), mentioning CORBA and some other casualties along the way. From another perspective, the Model-View-Controller (MVC) architecture pattern and its derivatives (including the most evolved Model-View-Presenter, or MVP) are again another attempt to achieve similar things: low coupling, a possible reusability of a same model between different applications, etc. While MVC/MVP aren't an alternative to SO, the later actually complements the former in what respect to accessing the model. Although they looked as belonging to two different camps, what is evident is the fact that both techniques were intended to decrease the cost of developing software
The architectural landscape is plenty of examples like this one
User eXperience (UX) is probably another topic that, treated in isolation, seems to be self-contained but when you double-click on it there's (happily) a lot of other architectural concepts that are clearly related with. So let me tell first how this thought was initiated, and later I'll show you how almost all in Software Architecture, sooner or later, attempts to provide a better experience for users
A friend of mine, architect he, found me in a book store some months ago. I was checking a stack of books on UX, so he asked me if I was about to design UIs for some applications and needed to improve my skills. That wasn't false, I mean, my UI design skills are actually very poor, but the real reason I was checking on UX (let's observe I didn't say UI but UX) was because I was to spend the next months analyzing and writing architecture recommendations on UX. He seemed a bit disappointed about that, as he let me know: on his view, the architectural story on UX is very short, "just have some graphical designers doing the UI with usability concepts in mind, some developers coding the behavior... and it's done! The rest is solutions architecture as usual. How much more can you say about that? Maybe, updating the speech to the current line of products, you can mention Microsoft Expression for UI designers, Visual Studio 2008 for developers, XAML as lingua franca for both and that's all, folks!"
Before going ahead ask yourself, honestly, do you realize why my friend's point of view is a simplistic one? Do you, instead of that, share his view? If that is the case, I hope I can change your mind in what follows
The first misconception that leads to opinions like the previous one is considering that User eXperience (UX) is all about the User Interface (UI). Actually the opposite is likely to be right in the sense that UI is a very important part (surely not the only one) of UX. Probably UI's importance among other disciplines affecting UX is due to the fact that any decision, any change in the interface is immediately perceived (even if we just display the interface, without actually using the application it belongs to) with all our human senses (mostly, our vision and tact)
If we interpose a cache in order to reduce some network latency originated on front-end / back-end round trips, the experience of using our application will be enhanced as we won't wait anymore for those most common (and thus, already cached) queries. However, that improvement didn't involve any change in the user interface
Next, I'll enlist a series of nowadays trends, debates and disciplines in Software Architecture, showing how the search for a better User eXperience is, in last instance, a motivator of those
Web 2.0
Enterprise 2.0 | - Applications in this range are designed to take advantage of network effects. In other words, the more they are used, the better results they offer to their users (more accurate, more complete, etc)
- The long tail coverage brings more productivity to users, as the information is segmented and classified to flow toward them in a proactive manner
- Rich Internet Application (RIA) technologies like AJAX or Silverlight, from a UI perspective this time, help achieve higher levels of responsiveness
|
| Service-Oriented Architecture (SOA) | - As the different, formerly isolated, silos are being integrated, data gathering phases release the user of entering large amounts of info in those cases where such info can be taken from some federated services. This is not only less error prone but it also alleviates the user to have already entered information at hand
- The orchestrated model suggested by SOA carries a better overall response time as certain composed processes (belonging to a variety of platforms) can now be performed in a streamlined manner (either synchronously or asynchronously). In the past, those operations stayed pending of the execution of nightly batch processes, postponing to user for any answer (either positive or negative) to the next business day
- As the service orchestrator consolidates answers from one or more sources, any device able to get the orchestrator can expose such functionality to its users. Therefore, from the user's perspective, SOA applications are likely to be available in more than a single device (web, desktop, cell phones, ATM, POS, etc). Even considering that not necessarily all the functionality can be exposed on every device
|
Software as a Service (SaaS)
Software + Services (S+S) | - The dynamics of this software delivery model implies that just a small footprint needs to be installed on the desktop (in the SaaS case, eventually nothing is left there). That way, is very easy to release new versions of the services with 0 (zero) impact on their clients (which thus enjoy always a latest version)
- Personalized features and data follow the user, wherever device she uses to access the services
- From the user perspective, there's no need to worry on infrastructure administration (backups, availability, etc) as usually there is a SLA clause establishing the SaaS provider as responsible about that
|
| Agile Development | - The user doesn't have to wait so long to get software updates, mostly focused on her current primary needs (as a drawback, user dedication for feedback provision must be promptly)
- As applications are built based on so-called User Stories, the resulting software tends to be user-centered (let's consider that user-centered design is one of the techniques to maximize the application UX)
- Acceptance and stress tests help anticipate unexpected application behavior with an evident impact in the UX (low responsiveness, inaccurate answers, etc). Testing is a phase present on several development processes, not just the agile ones. However, Agile processes make an optimal management of these test cases
|
| Identity and Access | - Latest integration of biometric mechanisms helped the user avoid remembering complex passwords, being obliged to change it often
- Federated applications relying on a common identifier authority release the user of those applications to remember possible different credentials, and reenter those as well, with no need to impersonate generic users (being obliged to track the original requestor for auditing purposes)
- In case of application unavailability, remote login facilities help inspect the health of an application or its server without needing a physical presence (getting the downtime shorter)
|
| Management and Operations | - Monitoring indicators based on SLA health models fire alarms intended to react proactively before users notice that something is going wrong, reporting that to the call center
- Smart deployment technologies like Java Web Start (JWS) or MS ClickOnce take care of application delivery/renewals with little or no user intervention (trend known as no-touch deployment)
- .NET Shadow Copy, farms, load balancing, graceful degradation, failover and other techniques were created to maximize the ability of having highly available, yet scalable applications regardless the number of users
|
| Performance Tuning | - Caching techniques, as mentioned before, are applied in those places where we don't want to have a user awaiting for an answer, with the risk of switching to another way (i.e. competitor service) to carry her duties without sacrificing personal productivity
- High-Performance Computing (HPC), while an expensive solution yet, is applied where an answer is required in humanly reasonable times
- Asynchronous programming models and callback techniques emerged to bring responsiveness to our applications in terms of user expectations
|
The list could follow. Summarizing all as final words for Software Architects, there's a lot to do from our side to help our applications get a better (if not the best) User eXperience. As we could see in the list above (for sure incomplete) every architectural decision we take affects positively or negatively the experience that our applications offer to our users (customers, employees at our same organization, etc). Therefore, from our perspective (the one of Software Architects), studying UX-related issues is not just getting a state of the art on UI technologies and innovative devices, but actually understanding how they fit in the general picture (if they do). Complemented with the remaining current debates on Enterprise Architecture, we must extract conclusions on how the UX is affected by all those, in order to take better decisions for our next releases
Clearly a long road to traverse. With this first I inaugurate a series of blog posts on User eXperience (UX)... for Architects, 'course!! 
A bad habit of several developers has to do with entering in a long tunnel of coding for an application project, relegating a more or less acceptable executable for the last project stages. That has several risks:
- Feedback from users and customers delayed, what can carry a poor customer satisfaction for who was going to receive the outcome. Business are in constant change so late delivery can bring outdated results
- Urgent and/or expensive changes for the developing team, and in those environments of changes made under great pressure, conditions for bugs proliferation are optimal :-D
- When that happens, when bugs are running everywhere, the vicious circle recycles: more urgent and/or more expensive changes with even better conditions for bugs generation
- Those can lead to a dead end known of project paralysis, manifested in the moral of developers, analysts, architects and project leaders, due to the fact that every initiative to regain control is anyway expensive and requires, although the previously invested effort, a new one greater
- This project paralysis can affect also the user / customer side, when the confidence on the outcomes is ran out
- After this happens it