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 comes… Not. Nothing comes after this: when the confidence runs out, the project is over
So the key here is achieve a schema of frequent builds for iterative, incremental running results. But trying to adopt that practice manually is stressful and could lead to early lack of motivation
So the key of the key has to do with automating the building process. Turning it to a industrial scale. Fortunately several tools can leverage us with building automation (MSBuild, NAnt, NMake), unit testing (NUnit, NUnitForms, Visual Studio 2005 Testing support, etc) and code analysis (FxCop, ...)
In his ninth chapter on the webcast series "Architecting Desktop Applications", PhD. Joe Hummel will show us how static code analysis prevents, in compile-time, design rule breaching (for instance for security, low coupling, performance, naming conventions, etc) thanks to a built-in VS2005 extensible mechanism known as FxCop. This feature is fundamental in those cases where source code is being written by several people with different styles, background and knacks
Also, learn how repeatable unit testing helps you keeping component health under control for those sudden changes with VS2005' Testing projects and its assertion mechanism. This will surely avoid several debugging hours. Here, the code coverage will give us a reliable estimation about how many code is really being subject of tests (with the possibility of finding out which code lines aren't)
Finally, you'll be taught about scaling the process of building, analyzing the code and running the tests through a facility included with the Visual Studio 2005 distribution called MSBuild. MSBuild is the process that VS2005 launches in background every time we select rebuilding our project. Here you'll see how to schedule MSBuild to build our project with a regular frequence. What about nightly builds, for instance? That would be helpful to know, as soon as possible, if a newly integrated source file is making fail some tests
So, what else can I do? Just point where the webcast is:
Build, Build, Build, Test, Test, Test
In n-tier, distributed applications, we have to decide which logic deploy where. Those deployments are all about installing components in specific places but, what are components exactly? What distinguishes a component with respect of a mere class?
Actually, as classes do, components take ownership of cohesive responsability but components are logical units from a physical perspective. In MS .NET terms, components are redistributable assemblies (.dll) of one or more classes
But, wait, it's not so easy: new considerations arise in this context
- Security: When one part delivers a component to some other, how can the receiver be sure he/she's loading the original component (not tampered, not violated in any way). How can the sender be sure that calls to his/her component come from the receiver and not from someone else who got an illegal copy of the component? How can we protect, given a component, about illegal decompiling, illegal use of reflection on it and, most of all, illegal inheritance from one or more classes which, under the façade of the expected ancestor, expose a different behavior than expected?
- Versioning: how to deal with different versions of a component without breaking usage for legacy clients of such component? In the previous infrastructure, Windows DNA, such issue was known as DLL Hell
- Configuration: where must be put, in the Setting.settings project file or in the app.config file? What if the solution has several project-components? Where the component config info has to go in such scenario?
In this eighth webcast, Dr. Joe Hummel focuses on the design and creation of .NET components. He explains what component references are and how the .NET CLR deals with them via component metadata
With respect of security issues, Hummel offers some notions on Threat Modeling and how to avoid it via strong-named assemblies
About versioning, know the benefits of the .NET's Global Assembly Cache and how it says bye-bye to the Windows Registry (leaving behind the DLL Hell)
Finally some notions of pluggable components or, said in other words, what role play in .NET the elements configuration, configSections, sectionGroup and section? What role plays the applicationSettings element? Tired of being tired of never finishing to understand it?
So come on, join us again and let's watch together a new chapter of Dr Hummel's series "Architecting Smart Client applications"
Turning Tiers into Components
What is exactly software architecture? Do we really need it? Why have we only recently been discussing it? Is there suddenly a contagious fever about software architecture infecting those who claim to be architects? Who are they actually: gurus, just senior developers, or maybe smooth-talkers?
These are questions that developers, junior and senior, are asking about software architecture and software architects. In this article we, the members of the MS Architecture Strategy Team, will answer all of them and even more: we will face the forbidden question “Can a developer become software architect?”
The Need for Software Architecture
A longtime ago, programming platforms were more self-sufficient than nowadays. From robust and complex environments like mainframe COBOL to light and easy to understand xBase languages, the most important technical decisions were already taken. In terms of software projects, that implied both benefits and deficits. A benefit, because where a decision exists, no time needs to be spent in discussions about the best way to do anything.
In non enterprise environments (academics, small business), this solutions model was adequate and successful for a long time. But it was a deficit as well, because at the largest companies, there was one notorious downfall - “all-or-nothing” platforms were too rigid to adapt to the competitive, highly changeable environments required by a global economy. Also, during mergers and acquisitions, it’s really hard to get two self-sufficient platforms to play togetether.
Thus, component-oriented software was born with the goal of a new agility in scaling applications. This style of applications enabled us to choose among a broad set of platforms, to produce modular pieces (or components) ready to be used by other components made by us or bought from third parties. Once we could prove that integration was not an issue, this feature gained popularity in the enterprise, where the technical decision makers discovered the advantage of using the right platform and tools as solutions for specific problems. However, eventually the need to plan and manage components became evident to guarantee the success.
Defining Software Architecture
So, thanks to component-oriented software we could choose the platform which best fit a specific problem. Despite that, the paradigm shift of new platforms was difficult to learn for many developers. Thus, one of the first objectives of a good architecture was to gently hide the complexity of new platforms and APIs behind simpler ones, more focused in the context of the problem being solved (typically a business problem), and, most of all, easily understandable by regular programmers.
That way software architecture became a highway to develop business solutions in a timely, secure, accurate manner. Under the pavement of that highway is nothing but technological decisions, the critical ones. Decisions the architect had to take to make the developers’ tasks easier.
The difference with past platforms is that now, rather than buying general purpose software from a vendor, an organization’s members make the decisions regarding the function of the business solution to be developed.
What Software Architecture Used To Be
Software Architecture emerged from a bundle of practices that applied by senior developers. Some of these merit mention:
· Design Patterns. The legend started with a book called simply “Design Patterns” (http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612) that is still a best seller. These patterns cover highly decoupled, reusable solutions for frequent problems about responsibility assignment in object-oriented programming (OOP). Actually, they merely solve the problem at a small scale, but surely this book sowed the seed for a new way of thinking about applications, constituting the DNA of several enterprise systems. We suggest as a reading the article “Last Call to Design Patterns,” at http://www.skyscrapr.net/blogs/solution/archive/2006/07/30/248.aspx
Figure 1. The Strategy Pattern, as explained in MSDN Magazine (July, 2005)
· Architecture Patterns. In the days of Smaltalk, one pattern proposed an extraordinary way of decoupling user experience from persistence mechanisms. This pattern, the Model-View-Controller, granted the responsibility of user interaction handling to a component which played a role known “the View.” “The Model” component had the responsibility of consistently keeping the business model state. A third component, called “the Controller” interpreted events originated from the View, promoting changes in the Model state accordingly. This pattern permitted very inexpensively interchanging components of any role, thus enabling multi-channel applications (that is, applications available in a vast variety of platforms and contexts). Think beyond the typical dichotomy of client versus server. Think of ATMs, mobile phones and other platforms. We have just to re-implement the View component in these use cases (“Bill payment,” “Book service,” and so on). The same applies to the Model. It isn’t just a discussion about Oracle versus SQL Server versus IBM DB/2 versus MySql vesus whichever. Think also of legacy mainframe environments or XML files for smaller data repositories (useful to easily mount development environments where the whole infrastructure could not be present). This pattern brought not just execution distribution but development distribution. Development could be better organized in different teams working in an asynchronous manner thanks to the inherent decoupling capabilities of this pattern. An interesting reference of this pattern is available at http://www.skyscrapr.net/blogs/solution/archive/2006/08/07/262.aspx. But MVC was just the beginning, because since the middle of nineties a series of books appeared to classify and organize many other architecture patterns. We must merely mention and recommend the POSA books (Patterns of Software Architecture), Sun’s Core J2EE Patterns, Martin Fowler’s series and, -with the launch of .NET - the MS Patterns and Practices guides. (Which include an interesting, ready-to-use set of application blocks, see Frameworks.) For more information visit http://msdn.microsoft.com/practices/
.gif)
Figure 2. The MVC Pattern, as explained in MS Patterns & Practices' book "Enterprise Solution Patterns"
· Anti-patterns. A counter-concept grew in parallel with the concept of patterns. If a pattern is seen as a best practice, an anti-pattern is a worst one. There is an infamous common anti-pattern, which aspiring architects and junior ones apply all the time: that of over architect all and every software component. This is commonly specially seen in the need of adopting immediately the new version of everything without actually considering if its benefits are helpful. Perhaps with the misconception that doing so will provide a comprehensive, easy to change architecture in some near future. But experience is showing that the opposite is happening - nobody wants to touch unnecessarily complex solutions so they remain “as is” until they are completely replaced. For a discussion about this, we suggest this article http://www.skyscrapr.net/blogs/solution/archive/2006/08/28/282.aspx.
· Frameworks. In a remarkable effort of enabling large scale software production, a variety of component blocks (better known as frameworks) appeared. There are frameworks to solve the gap between the domain object model and the relational database schema (called Object/Relational Mappers); there are other ones intended to achieve a clean MVC componentization; and recently, a new generation of dependency-injection frameworks is dominating the scene. Dependency injection allows a component to not to be responsible for knowing what its dependencies are, it just has to know which interface they expose. Thus, any tier change will not impact on its associated classes, because they don’t know each other directly. The undeniable success of dependency injection frameworks coined a reputation for them as lightweight (application) containers, in opposition to heavy, all or nothing solutions. There are some other specific purpose frameworks: integration, monitoring, and so on. These all share one concept: to keep developers focused on business logic (functional requirements) instead of cross-cutting aspects like security, manageability, and other non-functional requirements.
Emerging Architect Roles
The considerations of economical changes like globalization and technological achievements like the Internet’s impact 0n the digital economy, pressed for formalizing software architecture as a discipline.
Although there is not yet a definite agreement in the distinct roles, we can sketch three major personas:
· Infrastructure Architect. These define the platform and other environments (hardware, basic software) to provide for business applications’ high availability. They must also work with developers to define mechanisms and standards that allow applications to achieve the security, reliability, manageability, transparency, and policy compliance essential to the modern business. It’s expected that the natural evolution of a senior IT professional is an Infrastructure Architect.
· Solutions Architect. These are responsible for the design of one or more applications or services within an organization, usually within the scope of a division (and for that reason also known as Application Architect). Examples of such applications are: Internet banking, companywide knowledge sharing portal, and distributed point of sales applications. A senior developer is a good candidate to become Solutions Architect.
· Enterprise Architect. Their job is to keep the business and its IT systems in alignment. They strive to maximize the return on IT investment by making sure that IT spending is prioritized towards business opportunity, and by optimizing the impact of investments across the organization’s portfolios of services, resources, projects, and processes. They must be a bridge between business leaders, development, and operations to ensure that mutual understanding is achieved, goals are realistic, and expectations are properly managed. Enterprise Architecture is about the big picture — how people and technology work together to produce world-class, long-term results. For that reason, this persona is also referred as Strategic Architect. What is expected is that a Solutions Architect or Infrastructure Architect becomes Enterprise Architect.
What Software Architecture worry about nowadays
Recent years have been really challenging for software architecture. An elemental concept like service-oriented components (and its, as time goes by, more winner implementation: the Web Services), gave place to a whole enterprise strategy known as Service-Oriented Architecture (SOA). SOA has as a goal the complete connection of the business application portfolio.
.gif)
Figure 3. A Service-Oriented Architecture as told in the MS Architecture Journal (January, 2004)
Former silos like company CRM, ERP, and every line of business (LOB) application, are expected to enable their functions to the others for synergy and mutual profit. The SOA challenge is scattered in five major problems to address:
· Federated Identity and Access: How to manage the authentication and authorization systems in a centralized way, available for every application? Once the user logs in, how to propagate his identity to every service? How to treat external customers with respect to internal users? As just another role or maybe a completely different policy should be considered?
· Federated Data. How to keep the distributed repositories synchronized? How to gently gather enterprise entities by data aggregation? Which levels of redundancy are reasonable? How to deal with offline situations?
· Business Processes. Service-oriented components are granular pieces combinable in business workflows. Thus, every service could be seen as an activity to be executed in a definite order and upon definite conditions. The workflow engine becomes a sort of infrastructure piece in a SOA.
· Service-oriented components. There are four tenets that the pieces must comply with, to meet the SOA goals: explicit boundaries, autonomy, contract sharing, and policy-based compatibility. Those premises are better discussed at http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnbda/html/SOADesign.asp.
· Integrated User Experience. What does an SOA UI look like? There is a new range of UI frameworks around the concept of composed applications. We can find examples of them in CRM solutions and Web portal engines, where the UI is built through a combination of simpler, connected UI components.
The MSDN Architecture Center provides a complete reference about these capabilities: http://msdn.microsoft.com/architecture/solutions_architecture/default.aspx.
Where Software Architecture Goes from Here
While now concepts like patterns and SOA became or are becoming mainstream, software architecture continues evolving and expanding to new spaces. Because of space, we cannot discuss some other software architecture trends which build on SOA, like model-driven architecture (MDA) or software factories, but you can find more information at http://msdn.microsoft.com/architecture/factories/default.aspx.
However, there are two particular topics, not yet massively embraced, but watched very closely by the industry. (Usually, the industry is interpreted as the most important companies, IT analysts, and global system integrators.) They are:
· Software as a Service (SaaS). A new software delivery model, where companies don’t really hold their line-of-business (LOB) software bits, but only its right of use. That way, a new concept of software provider emerges (the so-called SaaS provider). Clearly, from the enterprise perspective, the inclusion of such software implies a certain impact. How to combine an SaaS application, for instance, in the company’s SOA? How to manage identities, workflows, and so on? From the provider perspective: a multi-tenant issue arises. If the provider is renting the software - its infrastructure -, to more than one enterprise customer, how can they enable further customization? Consider as examples various database schema; country policies that impact business processes, and other customer-specific modification. Perhaps even more pertinent, how to scale the environment for a growing number of tenants? The MSDN Architecture Center granted this topic its own space: http://msdn.microsoft.com/architecture/saas/default.aspx.
· Web 2.0. Another area of architecture research is how to get the most of the writable Web, Web based on participation. We talk about the Web ads, blogs, wikis, and other implementations. Those participative applications have existed for a while. The point is how companies can benefit from them, merging these kinds of community applications into their enterprise architecture. How to offer “the long tail” of those goods and services, each of which individually may not be the most wanted (possibly the least), but surely all of them together are becoming important in terms of revenue.
Conclusion
Some pundits wonder if being an architect is a condition they are born with or if it’s something acquirable with discipline and practice. In Microsoft, at the Architecture Strategy Team (AST) we are convinced that being an architect is a condition you can gain. SkyScrapr, http://www.skyscrapr.net/, is a community space for aspiring architects to share ideas, common knowledge, experiences, and - most of all - to discuss architectural issues.
Here we have reviewed how software architecture evolved from what software engineering was realizing about its existence.
The first software architects were de facto architects, in the sense that nobody officially granted them such titles. It was just a common perception, a sort of consensus.
But now software architecture is leaving behind its alchemist stage to become a real scientific discipline. Microsoft is contributing with the generation of a common space, an architecture collective community to make this real.
In "Last Call To Design Patterns" we described design patterns as "reusable solutions for frequent problems". It's all about thoughtful approaches to avoid common pitfalls
And, actually, Patterns are just one of a set of disciplines which help us to achieve software easy to understand and maintain. But, as PhD. Joe Hummel states in his seventh installment of his series "Architecting Smart Client Applications" on "Architectural Best Practices", best practices come at many levels (statement, method, class, architecture, proc