Beyond Software Architecture: Creating and Sustaining Winning Solutions 1st Edition

Beyond Software Architecture should be required reading for anyone starting a software company - that is unless one prefers the school of hard knocks!Luke does a fabulous job of going beyond the many books written on software and technology and beyond the many books, classes, and seminars addressing how to create a successful startup and get funded.Hohmann's keen insight and practical advice can make an enormous difference for any group of bright and knowledgeable software engineers and/or visionary entrepreneurs with the "killer" application - a difference that can mean success. He clearly defines the space between the technology and the market and draws them together so that technologist and business person alike can gain a necessary understanding for what it takes to bring to market and sustain a successful software product.I wish that this book had been available ten years ago and that I had read it!

This was a gift for our son. He seems to enjoy it. It was on his list.

There must be hundreds of books on the software developmental process, but I have yet to see a book that covers the business, technical marketing, sales cycle, deployment cycle, release cycle, licensing, installation, upgrade cycle, and everything in the middle all in one compact book. This book TRULY covers the life of a software application and everyone involved in it.For us techies, this book starts with what we are familiar with: "Why software architecture matters?" The author starts with a general overview of the topic, but it goes much further into the non-technical details software architecture, such as the Social Structure aspect:"A good architecture works for the team that created it. It leverages strengths and can, at times, minimize their weaknesses. ... Once created, the architecture in turn exhibits a strong influence on the team. No matter what language you've chosen, you have to mold the development team around it because it affects such as things as your hiring and training policies."New comers to the architect world don't really think about such aspects, or at least it's not really high on priority on many people's lists. The author puts such things right next to profitability, stability of the architecture, and defining the technical boundaries. Granted that Social Structure aspect of the architecture is as important as the others, you can't really find many books out there that treat it as such. Personal experience teaches us that, but there are cases, many cases, that one doesn't have the luxury of "trial and error". The author takes great pride in his experience and has written this book like a personal assistance to a newbie to the job, and to the expert architect with topics such as branding issues, licensing affects on the overall architecture and more...Tarchitecture and Markitecture are two words/concepts that are used frequently throughout this book. The author starts with the inception of software applications and explains the important rule that Market Architecture (Markitecture) and Product Management have in the overall picture of a software lifecycle. Why Business plan is important and how it should be written, how to release version 1.0 and subsequent versions, how customer input and interaction with the markitects play the most important rule in the subsequent releases of your software, and other such important questions are covered in chapters 2 and 3.The chapter Software License and Licensing models is probably one of the most valuable chapter (chapter 4) in the entire book. The author describes the concept of licensing and how it fits into the overall architecture and how it affects the architecture very elegantly. Various licensing models and their pros and cons are described:· Time based· Transaction based· OEM bases· Metering style· Hardware based· Services based· Revenue Obtained/Costs saved.The author explains why it is important to select the right licensing model, and how and why it could have a negative effect on your architecture if the wrong one is chosen. Various options for choosing a model are then explained such as the Honor System, the homegrown license managers, and the third party tools available.Another important aspect of software architecture - the-after-development-has-been-done-now-what aspect, is covered throughout the rest of the book. Deployment, installation, configuration and upgrades are the key topics. Other topics such as extensions to the current architecture, logging and branding are also covered in detail.The chapter on installation is another well-covered chapter that talks about a topic not covered at all or well in other books out there. Various deployment architectures are covered; Customer site installation, ASP, Managed Service Provider, and Web services models make up the topics for this chapter. This chapter, just like all the other chapters, relates the topic at hand to the overall system architecture, and why and how it can have an effect on the overall architecture of the system.Throughout the book, one theme screams out to the reader: "How every decision an architect makes affects the rest of the software life cycle, and what the architects need to think about and consider before coming up with their design?" The cycle - software life cycle, and how it is affected by the end user/customer, why it's the job of the market architects and business managers to gather the key points from their customers, what are some of the concerns that are common with any architecture (deployment issues, upgrade concerns, installation difficulties, logging and error reporting, security concerns), and tone of the most important aspect of all: Social aspects and how they have an important affect on the tarchitects, markitects and the overall application. I think the author says it best in the preface of the book:"You need to move beyond software architecture and move toward understanding and embracing the business issues that must be resolved in order to create a winning solution"

As a self-proclaimed "agilist," I have been in the habit of thinking more and more about ways that we can ensure that the software systems we build can richly and extensibly solve the business problems our customers need them to solve. And Agile processes like XP are certainly a big step in that direction. That's part of what attracted many of us to agility in the first place.In this excellent and timely book, Hohmann takes that desire for customer responsiveness a quantum step further, asking that every aspect of a software product (internal or external), from business model to architecture, be aligned with business purpose and business reality.To put it another way, he widens the software "project team" to include everybody and anybody who must dream up, define, design, market, sell, build, test, maintain, extend, support, and ultimately retire a system. It helps to systematize the hard and institutionally complex work of taking all of that input into account throughout the lifecycle.So the book talks about taking into account the customer-related input from all of the above roles. But it also asks us to keep the system responsive to all of the knowledge workers in those roles, and their continuing human needs. As hard as it is to do, it is not enough that a system be easy to extend for its programmers. It's not even enough that it provides the optimal feature set, on-time within budget. There is more hard work for it to do. Some systems are a hell of a lot easier to support than others, or easier to market and sell than others. And on and on.Hohmann shows us how the systems we build will inevitably end up responding to a wide range of needs and roles one way or another, and asks us to anticipate them all, embrace them all, and respond to them up-front, purposefully and systematically. I really, really like that. I can put these insights to use immediately.I think of the Agile practice revolution as an essentially humanizing revolution in software development, but at a fairly low institutional level. Agile practices largely help us only with the building of the system. And to the extent that Agile methods humanize that building process, they are great.But I think Hohmann's book gives us the start of a higher-tier, larger view of a humanizing movement, not just in building software systems, but in the entire lifecycle, the entire arc from conception to death. A humanized view of the lifecycle is a fabulous thing, to my mind. I think it really could change the software world permanently. We could all end up (gasp) loving our jobs.This is an important book, full of Aha! insights. If you have responsibility in any of the above roles I mention, I think you need to read it.