Real World Software Architecture

Real World Software Architecture is dedicated to providing information and experiences from the field of Software Architecture.



Subscribe with RSS or ATOM Add to Google

Links

  • Home Page
  • Real World Software Process Engineering
  • Suggested Reading
  • .NET Dev and Arch Collection
  • SEI Essays on SA
  • Software Architecture
  • Bredemeyer
  • wwisa
  • Product Line Engineering
  • PLEES
  • Software Product Lines
  • MSDN Architecture Center
  • patterns & practices






Tuesday, June 28, 2011

Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures Book Review

This is a book of patterns that achieve potential parallelism. It is very important concept that all developers should have a decent grasp on. The patterns teach you how to write programs that run faster when parallel hardware is available and about the same as an equivalent sequential program when it is not.

The book starts with an introduction to potential parallelism, tasks, coordinating tasks, shared data, and the limits of parallelism. It then has a chapter on each pattern which include Parallel Loops, Parallel Tasks, Parallel Aggregation, Futures, Dynamic Task Parallelism, and Pipelines.

It continues with some awesome appendices- Adapting Object-Oriented Patterns, Debugging and Profiling Parallel Applications, and Technology Overview. It ends with a nice glossary, references, and indexes.

The book does a nice job of giving examples in PLINQ (Parallel LINQ) and TPL (Task Parallel Library).

There is a great companion site located on CodePlex. You can download Answers to end of chapter questions, C#, F#, and VB code samples, Appendix B Color Figures, and a nice demo application.

The book is very well written and the authors do a great job of making what would seem like a complex topic easy to understand.

The thing I like most about this book is that there is no fluff. The book is all about getting you up and running, but up and running the right way with the right tools.

This book is a must read for anyone considering moving into parallel programming with the .NET framework.


Parallel Programming with Microsoft .NET: Design Patterns for Decomposition and Coordination on Multicore Architectures (Patterns & Practices)

posted by tadanderson at 4:52 PM 0 comments

Monday, June 27, 2011

Architecture Principles: The Cornerstones of Enterprise Architecture Book Review

My first look at his book was in PDF format. My friend let me borrow his copy. I liked it so much I printed it and put it in a three ring binder. I liked that so much that I wanted something more permanent so I bought the book. The book is pretty pricy for it's size, so you are not paying for quantity, you are paying for quality and it is worth it!!!

Anyone familiar with Software Architecture understands that quality attributes need to be identified, balanced against one another, and then met through tactics. Principles are a key to unlock the door that has quality attributes hidden away in some dark corner of your enterprise.

As an attribute of principles, your teams will have a better understand of the quality attribute they should be targeting when they are pursuing an architectural principle.

Architecture Principles are described in this book as the cornerstones in Enterprise Architecture and it definitely shows you why this is true.

The lack of Architecture Principles contribute to me hearing things like this-

-- We have an SDLC but we usually do not have time to follow it, so we are more agile. In other words, operating in chaos mode.

-- We have coding standards but they are out of date, so we usually just depend on our individual experience to guide us. In other words, we are still using the big ball of mud anti-pattern to design and code our applications.

-- We built the application now we need to figure out how to test it. In other words, we have no way of know if we met our capacity plan's performance requirements (usually this won't exist either), we can't regression test, and we are paying people to repeatedly do their best to bang away at the application and hope they find the bugs.

-- We have built logging in some places but now we have to figure out how to purge and archive the logs, and get logging into the rest of the application. In other words, we find architecture and design to be unnecessary overhead so we are used to missing things like this.

-- and so on and so on and so on…

This book starts out with a couple chapters that introduce and define enterprise architecture. It then continues with chapters that include A Conceptual Framework for Principles, Architecture Principle Specifications, A Practical Approach, Case Studies, Architecture Principles in Context, and Summary, Conclusions and Future Work.

The book ends with two appendices. One is a Principles Catalogue and the other is Architecture Principles in TOGAF. The Principles Catalogue is a really nice catalogue of 59 basic principles that can be used as a great starting point for getting started with defining your principles.

One of the things I like most about this book is that it defines the essential meaning of enterprise architecture as a normative restriction of design freedom towards projects and programs (or in a positive light- it reduces design stress). In 2005 I started using what I called Restrictive Development as a way to propagated my architectural constraints throughout the analysis, design, and the construction phases of my projects. It was nice to see I was not off base with my line of thought.

One of the things I didn't like about the book is that there is no index. There is a very small (1 page) Glossary and a thorough References section, but no index.

Although this book does not say it, I believe the most important thing this book does is to bring to light that architecture principles should be explicitly defined and implemented. Just like an architecture. It exists whether or not you execute a software architecture business cycle and define it or not. You just don't know what it is and have no way of controlling and improving it. Your enterprise has principles that are guiding your enterprise, but if you do not have them explicitly defined and enforced, you are just flying blind and those invisible principles are doing the driving.

This book is a must read for anyone involved with Enterprise Architecture in any way. Architecture Principles are a very very important topic and they deserve your attention

Architecture Principles: The Cornerstones of Enterprise Architecture (The Enterprise Engineering Series)

posted by tadanderson at 10:16 AM 1 comments

Monday, June 20, 2011

Enterprise Architecture at Work: Modelling, Communication and Analysis Book Review

If you want to learn how to do Enterprise Architecture modeling, this book is for you. The book covers the Archimate language in detail.

The book starts off with a nice introduction to Enterprise Architecture. It explains the internal and external drivers and then goes on to introduce the current state of Enterprise Architecture in the industry.

It introduces EFQM, ISO 9001, COBIT, ITIL, CMMI, IEEE 1471-200, Zachman Framework, TOGAF, and MDA. There is a short introduction to each, but it is enough to put them in context.

The book the talks briefly about the description languages which include IDEF, BPMN, Testbed, ARIS, UML, and ADLs.

Next there is a nice chapter named Foundations. Foundations outline the fundamental ideas on which the author's approach is based. Topics include architectural complexity, describing enterprise architectures, and pictures, Models, and semantics.

The last chapter before heading full steam ahead into modeling is Communication of Enterprise Architectures. The book then has chapters on guidelines for modelling, viewpoints and visualisation, architecture analysis, architecture support, and tool support.

The book then has three nice size case studies and wraps up with a chapter on what is beyond enterprise architecture. The case studies are of sizable systems, they are not just three hello world projects.

This book is in full color which makes the diagrams easier to understand. The book is small so it is easy to keep by your side. I like the writing style of the authors, they make it an easy and enjoyable read.

This book has tons of diagram examples in it. I use Archimate when I do Enterprise Architecture models. I use SPARX EA, but there is also a free tool available named Archi: Archimate Modelling.

All in all if you are an architect you owe it to yourself to check out this book and give Archimate a shot.

Enterprise Architecture at Work: Modelling, Communication and Analysis (The Enterprise Engineering Series)

posted by tadanderson at 9:38 AM 0 comments

Thursday, June 09, 2011

Handbook of Human Factors in Web Design, Second Edition Book Review

This is a huge book and there is a ton of information covered. Some of it in depth and some at a high level.

Most of the contributor's names are followed with PhD. That is not a bad thing, it is actually good, because the book does not read like it was written by people who's names are followed by PhD, but the material is PhD quality.

The book reads like a collection of thesis papers that have been translated for us mere mortals to understand. It is a collection of papers gathered into sections by topic, which means the chapters do not always flow into one another, but some do build on one another.

Some of the topics covered are Historical Overview of Human Factors and Ergonomics, History of Computers and the Internet, Human–Computer Interaction, Physical Ergonomics and the Web, Developing Adaptive Interfaces for the Web, Organization and Structure of Information using Semantic Web Technologies, Intranets and Intra-organizational Communication, User-Centered Methods for the Designing Web Interfaces, Task Analysis Methods and Tools for Developing Web Applications, Human Factors in Online Consumer Behavior, Analyzing and Modeling User Activity for Web Interactions, and Mobile Interface Design for M-commerce.

The book is very expensive and at its current price I can't say that the information you get out of it is worth the price or not. It will depend on how much of it you end up using and how much of it is new to you.

I am assuming it is so salty partly because of the construction of the book, which is very high quality. It is one of the best constructed book I have purchased.

The thing I like most about the book is that its chapters are self contained. I read this book in absolutely no order at all. I picked the topic I was most interested in and started there. I continued down the list of topics that interested me.

Each chapter is followed by a very extensive reference section that allows you to continue digging further into the topic if so desired.

Although the book is not in color, there is a nice section of colored figures. It includes all the figures that benefit seeing them in color.

One thing is for certain, after lugging this thing around for a month you are sure to be in better shape.

If you build web sites, and you care about your customers getting a high quality product from your efforts, invest in this book. I rarely pay $111.00 for a book, but I can say I am glad I did, this was worth every penny.

Handbook of Human Factors in Web Design, Second Edition (Human Factors and Ergonomics)

posted by tadanderson at 6:44 PM 0 comments

Silverlight isn’t dead PLEASE read this and stop the Nonsense

I have never seen so much noise over so little information. I am in the same boat as everyone else. I am worried about Microsoft's leadership and direction. Personally I am not happy with what I have been seeing, but all the Silverlight is Dead noise is crazy.

Please read-
Silverlight isn’t dead, it’s the heart of Windows Phone, Windows 8 and Xbox

posted by tadanderson at 6:49 AM 0 comments

Wednesday, June 08, 2011

Developers should Learn Why not just Memorize What

I have gotten a few emails asking why I read so many books. Simply put, I read books to learn about all the things the people who are much smarter than me recommend I do.

The one thing I learned in college is that if I wanted an A, I needed to work for it. I was not naturally smart like some of my classmates were. I am also horrible at memorization, so I had to learn why something was done and not just the formula to accomplish the task at hand.

I also learned that the more I learned the less I knew. Programming and architecture require a lot of knowledge, much more than my little brain can hold. So I read and what keep is the why something is done the way it is done. I also do my best to remember a reference to the location of what I read (which book I read it in).

This has burned me when memorization was a preferred skill over experience. I was in an interview once that had gone on for a pretty long time. Nothing technical was asked for hours. Then one of the interviewers came in and started asking very simple yet broad technical questions. The random memorization type. You know, define an assembly, list the new features in .NET 4.0, how many toes does a monkey have. Those type of questions.

My gears didn't switch, instead they locked. I could not recall the lists of things they wanted me to recall. I could actually remember the page number and the page layout the answer to one of the questions was on, but could not remember the content of the page.

It worked out for the best, the company I was interviewing with has seemed to have lost its direction. It also seemed they were interested in a road warrior, which I am no longer willing to be.

I don't feel bad about doing poorly in interviews that are just a bunch of random questions looked up by one of the interviewers 2 hours before the interview. I expect to be asked about my resume and grilled about what I have claimed to do. In the interview above not one question was about anything on my resume that day. It was one of the weirdest ones I have been on. I guess the point is, preferring memorization over understanding why something is done, does have its place in the industry, but I am not interested in those places.

I recently attended a presentation where one of the topics was the death of apprenticeship. The line of thought is that with all knowledge now available at ones finger tips, the only skill you need is to know how to use Google or any other electronic data resource. Experience no longer counts for anything.

Although I agree with this line of thought for certain jobs, I do not agree with it for Software Development (and many other professions that I am not qualified to talk about). Although I know there are a lot of developers that would disagree. There are a lot of them out there that believe all you need is Google and other people's code to succeed at developing software. Like I said above, I do agree with this line of thought, but with respect to learning the other's experience and understanding behind those code snippets they so kindly post. Just using the end result without understanding why you are using it, will come back to bite you later.

I have attended several technical review meetings over the years and sometimes I am simply left speechless when I hear something like "Now that we have the application deployed we need to talk about XXX". You can put security, logging, error handling, performance, testing, etc. in XXX. They collected all the pieces of what it takes to build the application, but no one on the team had any architectural experience to put them in place in the correct order. When I asked how they could be so far off base, I have been told … They see architecture as extra work that gets in the way of real progress.

My response is they simply don't have the experience on the team to know better. For those that have never seen architecture done correctly, they don't believe it is worth the effort. Most of those environments give a team of inexperienced individuals the responsibility to execute the architecture business cycle and they simply generate a whole lot of useless artifacts that are later viewed as a waste of time. They learned what artifacts to produce but never learn why you produce them and what the goal of producing them is. They were simply a check box on a list of "this is what is produced during the architecture process".

To me having information is knowledge, knowing what to do with the knowledge is wisdom. I see a whole lot of knowledge these days, but very little wisdom. As long as the shortcut to the end result continues to be taken, our industry is going to continue to produce garbage, but I guess that is not all bad for those of us who make a living cleaning up garbage.

posted by tadanderson at 5:21 PM 0 comments

Tuesday, June 07, 2011

Programming Microsoft ASP.NET 4 Book Review

This is the ASP.NET book a .NET Software Architect wants by their side. Not that it isn't good for a developer also, it just really focuses on all the things a .NET Software Architect needs to know about the technical aspects of ASP.NET 4.

This book covers all its material in-depth. A lot of the material is for advanced ASP.NET programmers. The author gives this warning at the beginning of the book.

The book has complete chapters on ASP.NET and IIS, Configuration, HTTP Handlers, Modules, and Routing, Core Server Controls, Input Forms, Data Binding, HTTP Request Context, State Management, Caching, Security, Ajax, and jQuery.

One of the things I did not like about the book is that it has cut the advanced aspects of ASP.NET and refers you to the author's previous book for those topics. This seems to be the new way publishers are saving money. Although I have seen some reviews that complained about all the previous material being included and bloating a book, I have seen 10x the amount of complaints about the removal of the material.

Another thing that annoyed me was the inclusion of material from one of the authors other books, Microsoft® .NET: Architecting Applications for the Enterprise (Pro-Developer) . It is not that the material is bad (actually it is great), is just is too limited to have an impact. It felt out of context. You should read that entire Architecting Applications for the Enterprise book, not just a few chapters from it. I would have preferred more technical ASP.NET information be included in its place.

The saving grace with respect to the two annoyances I listed above was that the author did not repeatedly refer to his other books. I have read some books that it seemed every five pages you were being told to go look something up in the author's other book before reading what they had written in their new one.

My favorite thing about this book is the level of detail the author goes into. He does a great job of providing the complete picture of all the topics he covers.

The chapter on security is great. It breaks down all the aspects of ASP.NET security including Where the Threats Come From, The ASP.NET Security Context, Forms Authentication, The Membership and Role Management API, Claims-Based Identity, and Security-Related Controls.

The code is very well organized and usable. It is all under one solution file.

I highly recommend this book to anyone doing advanced ASP.NET programming or doing .NET Software Architecture.

Programming Microsoft ASP.NET 4

posted by tadanderson at 9:57 AM 0 comments

SATURN Conference 2011 Presentations are Available

The SATURN Conference 2011 presentations are available for download.

Links to the downloads and descriptions of the presentations are available here.

posted by tadanderson at 8:19 AM 0 comments

Previous Posts

  • DevOps: A Software Architect's Perspective Book Re...
  • Scaled Agile Framework (SAFe) LiveLessons Video Se...
  • Bulletproof Android: Practical Advice for Building...
  • Swift for Programmers Book Review
  • Security in Computing (5th Edition) Book Review
  • Swift in 24 Hours, Sams Teach Yourself Book Review
  • Sparx Systems Releases Enterprise Architect 12
  • Learning Swift Programming Book Review
  • Android Security Internals: An In-Depth Guide to A...
  • Adaptive Code via C#: Agile coding with design pat...



Archives

  • December 2005
  • January 2006
  • February 2006
  • March 2006
  • April 2006
  • June 2006
  • August 2006
  • October 2006
  • November 2006
  • December 2006
  • January 2007
  • February 2007
  • March 2007
  • April 2007
  • May 2007
  • June 2007
  • July 2007
  • August 2007
  • September 2007
  • October 2007
  • November 2007
  • December 2007
  • January 2008
  • February 2008
  • March 2008
  • April 2008
  • May 2008
  • June 2008
  • July 2008
  • August 2008
  • September 2008
  • October 2008
  • December 2008
  • January 2009
  • February 2009
  • March 2009
  • April 2009
  • May 2009
  • June 2009
  • July 2009
  • August 2009
  • September 2009
  • October 2009
  • November 2009
  • December 2009
  • January 2010
  • February 2010
  • March 2010
  • April 2010
  • May 2010
  • June 2010
  • August 2010
  • September 2010
  • October 2010
  • November 2010
  • December 2010
  • January 2011
  • February 2011
  • March 2011
  • April 2011
  • May 2011
  • June 2011
  • July 2011
  • August 2011
  • September 2011
  • October 2011
  • November 2011
  • December 2011
  • January 2012
  • February 2012
  • March 2012
  • April 2012
  • May 2012
  • June 2012
  • July 2012
  • August 2012
  • September 2012
  • October 2012
  • November 2012
  • December 2012
  • January 2013
  • February 2013
  • March 2013
  • April 2013
  • May 2013
  • June 2013
  • July 2013
  • August 2013
  • September 2013
  • October 2013
  • November 2013
  • December 2013
  • January 2014
  • February 2014
  • March 2014
  • April 2014
  • May 2014
  • June 2014
  • July 2014
  • August 2014
  • September 2014
  • October 2014
  • December 2014
  • February 2015
  • March 2015
  • April 2015
  • June 2015
  • July 2015
  • September 2015

Powered by Blogger