Archive

Archive for April, 2010

Architectural Decisions and Their Consequences

April 28, 2010 Comments off
Following on from previous posts of articles taken from ‘design patterns for .net’


Architectural Decisions and Their Consequences  (by Rob Daigneau – design patterns for .net) – Read for full article, extract below.

Our customers continually challenge us to design and produce systems that are characterized by a plethora of adjectives. We’ve all heard the wish-list so many times, "We need a system that is agile, scalable, highly available, secure …" and so forth. While our hearts are certainly in the right place in our efforts to achieve such things for our customers, oftentimes we can be somewhat naïve concerning our own abilities to attain all goals equally on a given project. The truth is that we can’t have it all, and as architects we must carefully weigh the trade-offs and consequences of choosing to optimize for a given goal. It then follows that the difficulty of evaluating the consequences of our design decisions will only compound as the number of goals increase.

Shared Goals 

When it comes to software systems, every executive, manager, architect, developer, DBA, and customer typically hopes to achieve similar goals. We all want systems that have these attributes…

  • Adaptable: The system is easy to maintain, alter, and reshape when the need arises. This includes the ability to add (i.e. extend), change, or remove functions and logical sub-systems. The system is agile in that it can readily be adapted to reflect changing business requirements. 

  • Available: The system may be accessed and used in the intended manner when the users need or want to use it.
  • Efficient: The system does not place undue stress upon limited resources such as server or workstation memory, disk space, network bandwidth, and database connections, to name a few.
  • Interoperable: Applications or sub-systems easily integrate with other applications or sub-systems to create more complex "super systems". Sub-systems can be "weaved together" (hopefully in a loosely coupled fashion) to create a seamless information system that might even cross organizational boundaries.
  • Manageable: Individual parts of the system are easy to deploy and manage once they have been rolled out.
  • Responsive: The system has high throughput, acceptable response times, and is scalable (i.e. the ability for a system to continue to perform well as the load increases).
  • Robust: The system can recover from or correct run-time errors.
  • Secure: The system only allows individuals to access functions and data that they are authorized to access.

There might be a few more goals that we are asked to achieve as well …

  • Portable: Parts of the system may be moved to other operating systems, programming languages, database management systems, or other supporting technologies.
  • Chameleonic: The information managed by the system can be presented through a variety of means including various web browsers, rich clients, and mobile devices. The system’s presentation approach is smart enough to morph for different types of machines or operating systems, or perhaps can be "branded" for different customers.
  • Localized: The system uses languages, monetary units, and other aspects specific to a given geographic region.

There are, of course, some things that few of us would debate are not amongst the "must-have" characteristics. These include …

  • Accurate: The system accurately implements the business rules and correctly executes the tasks desired by the users.
  • Consistent: Business rules are uniformly implemented and common logic is shared throughout the system. This capability might also encompass the goal to have a user interface that has the same "look and feel" throughout.
  • Valid: The data managed by the system is always in a valid state; data corruption is not allowed.
  • Intuitive: The system is easy to understand and use. It allows people to work the way the want to work.

Is it really possible to achieve all of these things? In a world where time, money, and resources (i.e. developer talent) are unlimited, then the answer might be yes. Unfortunately, that is not the world we operate in.

A Trade-off Model for Architectural Decisions

It is usually beneficial to assess what the impact of a given design decision might be with respect to time (i.e. how long it will take), cost, and complexity. The diagram below attempts to show that a continuum exists between most goals (listed in the prior section) and these competing objectives.

 

 

For example, if we seek to achieve a system that is very responsive, then it will usually take longer to deliver upon that goal, it may cost more, and will probably entail a more complex solution. We can, however, seek to find some balance between these goals. In other words, we might decide that in order to achieve certain delivery dates, stay within budgets, and reduce complexity, that it may be acceptable to seek a level of responsiveness that is "good enough" for the business requirements, but not as fast as we might have hoped for if we were not constrained by schedules, budgets, or the capabilities of our teams.

This model does not suggest that there is a necessary trade-off to be considered between all goals and time, cost, or complexity. For example, if we seek to achieve systems that are highly adaptable, then oftentimes we need only consider what the impact might be on delivery time and cost. The rationale here is that highly adaptable systems are supposed to be delivered through designs that are characterized by lower complexity, which in turn allows them to be adaptable in the first place. The paradox here is that sometimes this adaptability does involve the introduction of greater complexity to allow such malleability. The trick is to abstract away this complexity from your developers through the skillful use of design patterns.

It should also be noted that sometimes certain goals can be difficult to achieve in unison. For example, if we seek higher degrees of interoperability between disparate systems, we might need to accept a trade-off in terms of overall system responsiveness.

Many believe that such trade-offs can be mitigated by "throwing bodies at the problem" (i.e. staffing up, adding more resources, etc.). I’ve found that, while it might be possible to use such a technique to both optimize for a given goal and achieve faster delivery times, the cost will still rise, and the level of complexity of the solution remains unaffected. Furthermore, the complexity of managing the increased number people tends to naturally rise in the wake of such a decision.

Conclusion

All architectural decisions involve consequences, some are beneficial, and others are less desirable.  As a parting analogy, consider what you might wish for in your dream house. If you were to present your ideas to an architect, and he provided an estimate in return, would it be possible that you might respond with, "Maybe I don’t need all that"? Technical Architects must have the ability to assess the trade-offs incurred by all design decisions, communicate these consequences effectively to their customers, and help everyone find the right balance between what are oftentimes competing goals.

This exploration is continued in Architectural Decisions and Their Consequences – Part II.

 

The Passage from Developer to Architect

April 28, 2010 Comments off
Following on from previous post of articles taken from ‘design patterns for .net’
 
The below topics relate to software architecture, the passage between a developer to an Architect and the debate of should a software Architect continue to code – however, coming from an engineering background as well as development to a minor extent, I see lots of parallels so you could equally read Engineer for Developer in these posts.
 

The Passage from Developer to Architect (by Rob Daigneau – design patterns for .net) – Read for full article, extract below.

Those who have been software developers for any length of time are probably familiar with the fabled crossroads where we must choose between a managerial path and a technical one. There is yet another crossroads we might encounter. When we are asked to play the role of architect, we must choose whether or not we will act as a "pure architect" who focuses on the world of abstract ideas, or if we will also continue to code (i.e. become a developer/architect). The compulsion to pitch in and help with the programming effort can indeed be strong. Most developers who want to be architects or think of themselves as such probably love coding, as do I, and leaving your love is hard. But if your goal is to become a professional architect, especially the enterprise species of architect, then you might have to consider leaving your beloved behind, at least in the workplace.

Yet Another Lesson from Star Trek

Remember the old Star Trek with Captain Kirk and Mr. Spock? If you’ve seen the series, then I’m sure you recall that every time a new planet was to be explored, the away team would always be comprised of the senior most officers including the Captain and the Chief Technical Officer. I always found this humorous. Anyway, in an episode called "The Deadly Years", the senior officers of the Enterprise (i.e. Kirk, Spock, McCoy, Scotty) are stricken with a mysterious illness that ages them rapidly and renders them incompetent. And if that weren’t bad enough, our heroes find themselves under attack by the terrible Romulans. Too bad for everyone, the leaders never taught their crew to run the ship on their own, or to become leaders themselves. They had no ability to function as a team and save themselves until McCoy found an antidote to the sickness, cured the Captain, and Kirk stepped up to save the day once again!

It’s a fun and dramatic if not a cheesy little story, but it’s also a parable for architects. Captains of starships and architects on projects are leaders, and leadership entails certain responsibilities. Amongst these are the requirement to provide goals to a team, ensure that the team understands the mission, stays on track towards that goal, and learns to function as a cohesive unit with less and less direction over time. The fact that the crew couldn’t function without the Captain was, in my humble opinion, a sign of very poor leadership. Kirk didn’t have a crew! He was the crew!

Architects who code are like starship captains that can’t delegate (uh, give up) dangerous planet explorations to their crew. You might love that job, but you might also find yourself marooned (in the code) while your ship meanders off into space. When you continuously move to the "front line" to code, your leadership takes a back seat.

Coding Limits Your Bandwidth

Just as captains of starships are accountable for more than are their crew, architects are accountable for more than are the developers on their teams. Rather than focusing on lines of code, routines, classes, and so forth, the architect’s calling is to attend to broader concerns. These include ensuring that the chosen technologies and technical designs achieve the business objectives, and that they do so within the given budgetary, schedule, and resource constraints. The architect’s responsibility rises from working on individual .Net assemblies, web forms, and web services, to planning for how all these things will collaborate to attain the goals of the company. As an architect, you’ll probably be thinking more about how different subsystems will integrate to produce products, than how to optimize certain blocks of code within those products. Architects can not possibly accomplish all of these things when they spend significant portions of time programming. Giving in to these urges only limits the scope of what they can do on a larger scale.

The architect must therefore let others do the coding while helping them stay on course. This is only possible if the architect provides a clear destination for the team to navigate towards. It’s certainly not easy letting go of the oars, but when you do, you’ll find that you’ll be able to take the helm, and by doing so will have a greater ability to handle a larger scope of concerns.

If you do find yourself jumping into the code, not only do you risk antagonizing the developers who may feel you’ve intruded in on their turf, but you might also be hurting their professional development.  This oftentimes occurs when impatient architects finds their developers or database engineers struggling with a problem that they know how to quickly fix. If the architect consistently comes to their aid in such a situation, they won’t learn. Instead, we need to let our teams make mistakes because this tends to enforce true learning. Remember that architects are responsible for more, and this greater responsibility typically includes the career development of others. 

What’s Happening to Me?

As your attention rises to bigger picture concerns, you will probably not be able to stay up with the ongoing changes to the languages, frameworks, and tools. This transition in one’s technical career can be quite disconcerting, and most feel that pull back to software development. You should consider resisting this pull in the workplace, and must accept the fact that you will not be the top-coder anymore. Because of this, it is wise to acknowledge to others when you don’t know something, and defer to their more current knowledge when appropriate. Don’t pretend to be the expert when you’re not.

You’ll probably find yourself attending more meetings than you did as a developer. I still recall on former teams when we used to joke saying that there were those who did actual work (i.e. the developers), and there were those who went to meetings. If you become an architect, you’ll be going to a lot of meetings, and will have become one of "them".

You’ll also have to deal with that dreaded word … politics! Everyone says they hate politics, but let’s face it. Where ever there are people, politics can be found. Architects need not fall prey to the "dark side" of politics (i.e. the idea that politics are always negative and are primarily concerned with the manipulation of people for your own benefit). Instead, architects should seek to work for mutual benefit, consensus, and compromise. You will certainly need empathy, negotiation, and facilitation skills in order to properly serve as an advocate for both the development and business teams, both of whom are your constituents. If the thought of these things turn your stomach, then maybe architecture isn’t for you. If, however, you take a chance, you may find that working through problems with people can be quite rewarding both professionally and personally!

The Passage

The passage from developer to architect can be scary and confusing. You may find yourself being “drawn to the light” of software development, and you must choose whether to go towards it or to take a different path. If you do follow that other path, you’ll find that the challenges and activities of the new role definitely make up for your forfeiture of programming. Remember, you can always keep your chops up by developing a web site as a hobby in your copious free time at home J

The Architetcture debate continued…

April 28, 2010 Comments off
Following on from some previous posts on the debate of the Architectecture discipline,  I found some interesting potsts on http://www.designpatternsfor.net that are a few years old but still relevant today. I will create a couple of entries on these posts.
 
In the below topic you could equally read Engineer for Developer in these post.
 

One of the reasons why there is so much disagreement over the definition of the word Architect is that those engaged in the debate seem to be reaching for one comprehensive definition for this professional label. The reality is that there are many species or types of architects, each with different concerns and responsibilities.

Many people in our community have posited the idea that the role of an architect unfolds as a continuum that starts somewhere around the time you become a more senior developer, and transforms in its nature up through positions such as CTO. This description suggests the wide variance in concerns that different types of architects might have, but is still quite vague. If you’re not a senior developer or an executive, where do you fit on this continuum, how does that translate into what you really do, and might there be a way to better classify the different types of architects?

"…Many would agree that the label architect is becoming more and more meaningless as an increasing number of organizations use the title in order to promote their sales agendas. Furthermore, many developers call themselves architects in order to elevate their own stature. For the time being, let’s forget about the negative connotations related to the word architect. Instead, let’s think about the role of architect, what it means to play that role, and how developers might move up to this role.

Perhaps a good place to start is by looking at the construction industry. Webster’s dictionary defines an architect as being…

"1. A person who designs buildings and advises in their construction. 2. A person who designs and guides a plan or undertaking."

I think that’s a pretty good place to start. All we need to do is swap a few words, add couple more, and this definition might work for our industry.

"1. A person who designs software systems and advises in the design of such systems. 2. A person who designs and guides a plan or undertaking related to software systems design."

Many of us are indeed architects if we use definition #1 as our standard. Even the most junior developer has valuable insights into how an organization might design and deliver software. Item #2, however, suggests a leadership role that somehow rises above mere counsel. The implication is that an architect has some kind of wisdom that will help the organization deliver software that not only meets the tactical and strategic objectives of the organization, but also considers the technical, fiscal, scheduling, and staffing constraints (to name a few) of the project. Such wisdom helps the organization identify the pros and cons of a given design decision and select a direction that optimizes the use of technology for the given business objectives and constraints.

If we accept that one of the characteristics of an architect is wisdom, the next question might be, "Where does such wisdom come from?" The quick answer is that it varies from person to person. Some people early in their careers have a natural talent that allows them to see how software designs might best achieve their objectives. Others, like myself, acquire knowledge over time by observing and studying how problems are solved on a number of platforms, in different languages, and by learning from our own mistakes.

Some believe that architects should be the best coders. I would argue that, regardless of the vertical industry you’re in, and whether you do corporate, commercial, government, or non-profit software work, this tenet if faulty. Let’s consider the world of building construction. In that world there are clear distinctions between specialists (e.g. carpenters, masons, electricians, etc.) and architects. In that world we can all understand the role of an architect, and we would never expect the architect to be an expert carpenter, mason, or electrician. Yet we all can accept that a building architect has to know enough about all of these things in order to envision, design, communicate with, and possibly direct and orchestrate the activities of such highly skilled individuals.

This analogy suggests that architecture is more focused on "the big picture", and that the architect turns to and delegates to specialists accordingly. This does not mean that the architect should ever let their coding abilities slip. On the contrary, the best architects keep on coding, they just may not dig into all of nuances of the latest framework, language, or platform. Most architects have learned that, when it comes to technology, specialized knowledge is a moving target and will probably be obsolete within 5 years or less. Architects are more concerned with how the current or "up and coming" technologies serve a "big picture" need…."

There are a couple of other observations I remember that also relate and tie in to the above….

Architect – An Engineer who knows what he/she is doing.
"If an Archtect says something that appears insane… Its because they are smarter than you"  Michael Lopp aka Rands (http://www.randsinrepose.com) on Definition of an Architect.

Miha Kralj- Microsoft Architecture Journal Article….

"…In the structural construction business, architects branched away from civil engineers and construction workers many centuries ago. They were (and still are) groomed, educated, and taught quite different skill sets than their engineering counterparts.

If you would ask a civil engineer what a building is, the definition will focus on thickness of the walls, angle of the roof, sturdiness of beams and type of concrete required for house fundaments. Architects on the other side will describe the house as a wrapper around the living space, nested into the environment that allows the inhabitants to do whatever they intend to do in the house.

How does that translate to IT, where we have borrowed the name and title of architecture? Our modern profession has not had centuries to diversify and evolve naturally. It seems that every high-complexity IT endeavor is now called architecture instead of engineering. In the words of Alan Cooper: "[nowadays] Web designers are called programmers, programmers are called engineers, engineers are called architects, and [true] architects are never called."


SQL Server 2008 R2 is here!

April 28, 2010 Comments off
SQL Server 2008 R2 is RTM
 
Take the Digital tour and find resources….
 
Categories: SQL Server

Get ‘Intune’ – Microsoft Cloud Management Services for PCs

April 23, 2010 Comments off
"Windows Intune simplifies how businesses manage and secure PCs using Windows cloud services and Windows 7—so your computers and users can operate at peak performance. Windows Intune delivers cloud-based management and security capabilities that can be administered through a single Web-based console, enabling your end users and your IT staff to work from virtually anywhere-all that’s required is an Internet connection"
Help manage and secure PCs virtually anywhere with the easy-to-use Web-based console, you can access alerts, reports, security policies, Manage updates, Track hardware and software inventory"

Help manage and secure PCs virtually anywhere with the easy-to-use Web-based console, you can access alerts, reports, security policies, Manage updates, Track hardware and software inventory"
 

Remote workers in multiple locations. Multiple PC configurations. Limited resources. These are just a few of the challenges that face businesses just like yours every day. Windows Intune™ is a new solution that can help you address these challenges, taking PC management to a whole new level of simplicity. With its powerful combination of Windows® cloud services, Windows software, and advanced on-site tools, Windows Intune offers a comprehensive solution to help keep your PCs and end users operating at peak performance."

 

Microsoft Productivity Vision & Sixth Sense Technology

April 19, 2010 Comments off

Microsoft Releases Technical Preview of Next Generation of Dynamics CRM

April 19, 2010 Comments off

"Microsoft has announced the Community Technical Preview 3 (CTP3) for the next generation of Dynamics CRM, code-named “CRM5.” This CTP is primarily aimed at software developers within the broad partner base of Microsoft Dynamics CRM, including independent software vendors (ISVs), global system integrators (GSIs), hosting partners and value-added resellers (VARs), giving them an opportunity to start early development and testing of their solutions for this new release."

See http://www.microsoft.com/Presspass/press/2010/mar10/03-25CTP3PR.mspx.

%d bloggers like this: