10 Things Every Architect Should Know

Download 10 Things Every Architect Should Know

Post on 11-Jan-2016

46 views

Category:

Documents

7 download

DESCRIPTION

10 Things Every Architect Should Know. Richard Monson-Haefel. 10 Things Every Architect Should know. Or. If you put 10 architects in a room and ask them to create a list of 10 things every Architect should know they will come up with either 10 different lists or a list of 100 things or both. - PowerPoint PPT Presentation

TRANSCRIPT

  • 10 Things Every Architect Should KnowRichard Monson-HaefelThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowOrIf you put 10 architects in a room and ask them to create a list of 10 things every Architect should know they will come up with either 10 different lists or a list of 100 things or both.

    This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • People are the PlatformApplications are for making users as effective as possible- Ben Geyer, Caterpillar Inc. This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • People are the PlatformWork on the things that matter most to customers first. - Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • This work is licensed under Creative Commons Attribution 3.0People are the platformBusinessPeopleUser InterfaceInformation Systems

    This work is licensed under Creative Commons Attribution 3.0

  • People are the PlatformDon't put domain modeling and service design on a pedestal and turn up your nose at UI and web work domain modeling and data management are not the hard or time-consuming aspects of a project, the UI is.- Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • People are the PlatformOne aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first and foremost, and our willingness to change prior decisions when we find they're not.- Luke HohmannThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • All solutions are obsoleteHope that nothing you do will last. - Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • All Solutions are obsoleteThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • All Solutions are obsoleteTodays solution is tomorrows problem- RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • All solutions are obsoleteUnderstand disposable applications. These didn't exist even as recently as two years ago, but the combination of social platforms, hosted business models, certain methodologies, and certain frameworks has made it less expensive to start over and re-architect certain kinds of systems than it is to make those systems extensible and evolve them.- Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Data is foreverTechnology, methodologies and business practices change, but data is forever- RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Data is foreverThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexity Decide where you want to build in flexibility, it doesn't come for free and it will always adds complexity.- Rebecca Wirfs-BrockThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexity SimpleComplexFlexible / ExtensibleRigid / ConstrainedThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexity Simplicity requires courage and time - it takes a lot of guts to hold the line on a simple design and several iterations to shake out the redundancies and noise to get there.- Don BoxThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexity The strength of a framework comes not from what it allows you to do, but rather from what it does not allow you to do.- Richard bergThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexity Adherence to or intellectual appreciation for a particular pattern is not an excuse to employ elaborate, complex frameworks that implement those patterns. Most new architects can't tell the difference, and are wedded to the expected solution rather than the actual problem.- Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Flexibility breeds complexityThe more things are stable the more disruptive they are to your architecture when they change. But that doesn't mean you should make everything changeable.- Luke Hohmann This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Nothing works as expectedIndependent of what the vendor says, the next version will not fix all your problems (and will even create many new ones).- Nitin BorwankarThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Nothing works as expectedGartner's Hype CycleVISIBILITYTIMEPeak of Inflated ExpectationsPlateau of ProductivitySlope of EnlightenmentTrough of DisillusionmentTechnology TriggerThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Nothing works as expectedGartner's Hype Cycle for 2007This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Nothing works as expctedNot all new technology is necessarily good technology, or better than older technology, just because its new and hyped and supposedly sexy- Randy StaffordThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Documentation is the Universal Source CodeA simple line of text is worth a thousand pictures.- Don BoxThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Documentation is the Universal Source Code1700 BC1800 BC1900 BC2000 BCThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Documentation is the Universal Source CodeRe-use is about people and education, not about architecture- Jeremy MeyerThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Know the business

    Business stuff and technical stuff are forever inter-twined. If you're an architect, learn to live in the white space.- Luke HohmannThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Know the business

    Architecting is about balancing the needs of all the stakeholders in a system, from users to CEOs to operations personnel to future programming staff, over the short and long term, in the way that is appropriate to the context at hand.- Randy StaffordThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Know the business

    The first few members of your team will define the culture of your team for a long time to come.- Nitin BorwankarThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Maintain the visionConceptual integrity is the job of the architect. And it matters. - Luke HohmannThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Maintain the visionDon't ignore (put your favorite quality here) until the last moment could be performance, security, scalability, whatever....all I know is when these qualities get shoe-horned in, the projects and architecture suffer. - Rebecca Wirfs-BrockThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Software Architects Should also be CodersIf you're unwilling to be hands-on, maybe you should keep your hands off.- Barry HawkinsThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Software Architects Should also be CodersGet out of your Ivory TowerGet into the trenchesThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Software Architects Should also be CodersPeople who are responsible for a given technology should write code against it (or better yet as part of it) every single day. Bits talk, bullshit walks.- Don BoxEvery architect should spend at least 10% of their time doing code reviews with the engineers building their product. - Don BoxThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • There is no substitute for experience

    You're not an architect until you've been working on the same system, and DEALING WITH YOUR CHOICES, for multiple releases. You're certainly not an architect just because you have a fancy title. - Luke HohmannThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • There is no substitute for experience

    This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • There is no substitute for experience

    Don't go looking for an architect after the foundation has been laid - Nitin BorwankarThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • There is no substitute for experience

    Creating great enterprise software isn't a matter of intellect as much as wisdom and tenacity -- the ability to see the similarity between one past experience (particularly a failure) and some aspect of your current context.- Sean NevilleThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • 10 Things Every Architect Should knowPeople are the platformAll solutions are obsoleteData is foreverFlexibility breeds complexityNothing works as expectedDocumentation is the universal source codeKnow the businessMaintain the visionSoftware architects should also be codersThere is no substitute for experience

    - according to RMHThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • More words of wisdom from seasoned architectsRembrandtThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Luke HohmannWe "give in" to great architectures. An architect or development team "gives in" to a design when they subordinate their experiences and expectations about what is "right" and instead lets the forces of the problem domain guide them in the realization of the architecture. Some people claim this is not a problem, and that they or their team always creates an architecture that is solely based on an objective understanding of the customers problems and how best to structure a technical solution. The operative word, of course, is "best". Your opinion of "best" may not match mine, and is probably more heavily influenced by my experiences than the problem domain -unless my experiences are borne from this problem domain. One aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first and foremost, and our willingness to change prior decisions when we find they're not.Give in to the architectureRead The Mythical Man-Month. Hell, memorize it.Conceptual integrity is the job of the architect. And it matters.Developers do what you ask them to do. So ask carefully (read Weinberg).Collaborate with your product management team so that you're architecture can evolve along with your roadmap. (Read Pattern Language for Strategic Product Management /Roadmapping).Business stuff and technical stuff are forever inter-twined. If you're an architect, learn to live in the white space.You're not an architect until you've been working on the same system, and DEALING WITH YOUR CHOICES, for multiple releases. You're certainly not an architect just because you have a fancy title. This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Rebecca Wirfs-BrockDon't ignore (put your favorite quality here*) until the last moment*could be performance, security, scalability, whatever....all I know is when these qualities get shoe-horned in, the projects and architecture suffer.Use patterns, follow accepted practices...don't try to re-invent the wheelThis work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Randy StaffordApplication architecture (not selected technology stack) determines application performanceThe number of IPCs in response to a stimulus usually drives response timeThere is no one-size-fits-all solution; the right solution is sensitive to context (see http://c2/com/cgi/wiki?ContextualSense)Architecting is about much more than just the technical aspects (of applying patterns, modularizing systems, optimizing performance, etc.); architecting is about balancing the needs of all the stakeholders in a system, from users to CEOs to operations personnel to future programming staff, over the short and long term, in the way that is appropriate to the context at handNot all new technology is necessarily good technology, or better than older technology, just because its new and hyped and supposedly sexyThe most popular product is usually not the most technically superior product (http://c2.com/cgi/wiki?WorseIsBetter)Everywhere I go, every day, I see money and opportunity being wasted by poor software architecture

    This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Nitin BorwankarDatabase design != SQL programming (most developers raised on MySQL do not know this) The first few members of your team will define the culture of your team for a long time to come (by hiring people like themselves)Stay away from projects that require you to be an architect and a project manager (if at all you can; sometimes you just can't)Don't go looking for an architect after the foundation has been laid (this one is for the project manager rather than the architect )This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Sean NevilleA problem's difficulty or intellectual attraction doesn't necessarily equate to importance or customer-relevance. Work on the things that matter most to customers first. Highlight the ROI story and customer story instead of the technical story to your Board and your internal team.Understand disposable applications. These didn't exist even as recently as two years ago, but the combination of social platforms, hosted business models, certain methodologies, and certain frameworks has made it less expensive to start over and re-architect certain kinds of systems than it is to make those systems extensible and evolve them.Hope that nothing you do will last. Software is less permanent than items produced in most engineering disciplines, therefore as long as our field continues to evolve and improve, none of your stuff will last very long (even legacy stuff gets ripped and replaced every 20 years or so) and most of what you know may eventually be wrong. It's still a young and rapidly-changing area with an element of Zen- like impermanence that is certain eventually to humble even the most brilliant software minds you know (including your own if you put yourself in that category).Don't put domain modeling and service design on a pedestal and turn up your nose at UI and web work. For most web and rich apps today, considering the tools, frameworks, and experiences at our disposal, domain modeling and data management are not the hard or time-consuming aspects of a project, the UI is. There's been a shift of R&D bottleneck away from devs and toward IA and designers on one end, and systems infrastructure guys on the other end.If most of your developers' time is spent on build processes, bug tracking, managing metadata files (XML or otherwise), etc. instead of coding or working with customers to solve problems, then you're not really agile, you've just moved the time bottleneck from one area to another far less interesting area.Learn the hardware that your stuff will be deployed on; you're not really a technical architect if all you know is a tiny slice of software in the overall system of hardware, economic, and network factors at play.Be careful not to degrade the person behind the platform/language/ technology/opinion you scoff at. Software is still a surprisingly small world, and while strong opinions and conflicts about technology are often healthy, personal conflicts on the other hand can have lengthy and unexpected consequences for you and your organization, so don't let your ego drive you into such unnecessary pitfalls.

    This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Sean NevilleOpen source is free only if you don't put a dollar value on your team's time. When creating budgets and schedules for exec staff, this must be kept in mind, though obviously filtered through the strengths of your team (which will occasionally render the point irrelevant). Lone wolf architects tend to make people suspicious and/or resentful. Find a partner. This is especially true of architects who have no accountability for budget or personnel, yet are accountable for the health of the system. Having an internal champion at your peer level or above who can advocate on the business side helps get things done. Sadly, this person is almost never your product manager. Network internally beyond the geeks in R&D to find the right person.The skills which will do the most to advance your career are quite likely not technical, but communication skills: writing, translating concepts into simple analogues and teaching them, coordinating in email across conflicting philosophies from different corners of the organization, pitching ideas to your Board or exec staff, etc. Written and oral ability is enormously beneficial.But on a negative corollary, people who write more books, papers, specs and presentations than they have written actual code and successful products are not generally the people you want accountable for the core of your code, no matter how intelligent they are or what their external reputation may be to the masses. But they do make brilliant marketing/evangelist/advocate -types. In other words, the team lead who spends hours on his blog answering questions or participating in forum arguments is not spending those hours working on the software itself.Developers tend to like writing code, but coding doesn't scale particularly well; small teams produce less code than large teams do, less code is less expensive to maintain than is a large body of code, and the least amount of code needed to do a thing properly and lucidly is the goal (discourage lines of code as a metric). Adding more people is not only not beneficial, it's detrimental (Mythical Man-Month).Many architects have a problem prioritizing and translating business priorities into technical priorities. The ROI story for most architects is the lowered overhead in developing and maintaining solutions over time, since in most organizations the architect is not creating a new revenue stream but rather reducing the cost of an existing process. This isn't true in some cases (example: building new software for commercial software companies dependent on software licensing as the primary revenue source), but it's true in most corporate cases. A problem's difficulty or intellectual attraction doesn't necessarily equate to importance or customer-relevance. Work on the things that matter most to customers first. Highlight the ROI story and customer story instead of the technical story to your Board and your internal team.Creating great enterprise software isn't a matter of intellect as much as wisdom and tenacity -- the ability to see the similarity between one past experience (particularly a failure) and some aspect of your current context and thus avoid costly downtime, or security problems, or concurrency issues (etc.) is often more beneficial to the larger organization and to customers than is your technical vision.

    (cont.)This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

  • Barry HawkinsValue stewardship over showmanshipThe only people who belong in ivory towers are captured princesses, and even that wasn't their choiceIf you're unwilling to be hands-on, maybe you should keep your hands off.The architect of software begins with a lower-case "a"; if you can't handle that, go do something else and stop inflicting yourself on others.This work is licensed under Creative Commons Attribution 3.0

    This work is licensed under Creative Commons Attribution 3.0

    *If you put 10 architects in a room and ask them to create a list of 10 things every Architect should know they will come up with either 10 different lists or a list of 100 things or both.***BioBen Geyers Software professional with 10+ years in software development working with various technologies to create useful business applications. Currently, He is a Technical Architect and part of the Enterprise Architecture group at Caterpillar Inc. *Full Quote:A problem's difficulty or intellectual attraction doesn't necessarily equate to importance or customer-relevance. Work on the things that matter most to customers first. Highlight the ROI story and customer story instead of the technical story to your Board and your internal team.

    Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Full Quote:Don't put domain modeling and service design on a pedestal and turn up your nose at UI and web work. For most web and rich apps today, considering the tools, frameworks, and experiences at our disposal, domain modeling and data management are not the hard or time-consuming aspects of a project, the UI is. There's been a shift of R&D bottleneck away from devs and toward IA and designers on one end, and systems infrastructure guys on the other end.

    Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Full quote from his book Beyond Software Architecture

    We "give in" to great architectures. An architect or development team "gives in" to a design when they subordinate their experiences and expectations about what is "right" and instead lets the forces of the problem domain guide them in the realization of the architecture. Some people claim this is not a problem, and that they or their team always creates an architecture that is solely based on an objective understanding of the customers problems and how best to structure a technical solution. The operative word, of course, is "best". Your opinion of "best" may not match mine, and is probably more heavily influenced by my experiences than the problem domain -unless my experiences are borne from this problem domain. One aspect of "giving in" to a great architecture is continually assessing if the decisions we're making are designed with the customer and their needs first and foremost, and our willingness to change prior decisions when we find they're not.

    Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/

    **Full Quote:Hope that nothing you do will last. Software is less permanent than items produced in most engineering disciplines, therefore as long as our field continues to evolve and improve, none of your stuff will last very long (even legacy stuff gets ripped and replaced every 20 years or so) and most of what you know may eventually be wrong. It's still a young and rapidly-changing area with an element of Zen- like impermanence that is certain eventually to humble even the most brilliant software minds you know (including your own if you put yourself in that category).

    Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Full Quote:Understand disposable applications. These didn't exist even as recently as two years ago, but the combination of social platforms, hosted business models, certain methodologies, and certain frameworks has made it less expensive to start over and re-architect certain kinds of systems than it is to make those systems extensible and evolve them.

    Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    ***Bio:Rebecca Wirfs-Brock is an author and consultant in object-oriented programming, the founder of the information technology consulting firm Wirfs-Brock Associates, and inventor of Responsibility Driven Design, the Design Columnist for IEEE software. She is a proponent of CRC cards (as part of the RDD design process), and, as she put it, the person who unwittingly spurred others to coin -Driven approaches.

    Books

    Designing Object-Oriented Software, with Brian Wilkerson and Lauren Wiener, Prentice-Hall, 1990, ISBN 0-13-629825-7

    Object Design: Roles, Responsibilities, and Collaborations, Addisson-Wesley, 2002, ISBN 0-201-37943-0

    *Bio:Don Box is a software architect currently working at Microsoft.Along with Bob Atkinson, Mohsen Al-Ghosein, and Dave Winer, Don was of the original four designers of SOAP, a basic messaging layer for web services.He currently works on Brad Lovering's team working on model-driven runtime and tool support at Microsoft. Prior to that, Don was an architect on Windows Communication Foundation (formerly known as Indigo) and related technologies.Before joining Microsoft, Don was a contributing editor and columnist at Microsoft Systems Journal, which later became MSDN Magazine. Don was also a conspicuous figure in the Component Object Model (COM) community, where he coined the phrase "COM is love." He is also a series editor for Addison Wesley where he launched two successful series targeting the Microsoft developer audience.

    BooksEssential .NET, Volume I: The Common Language Runtime, with Chris SellsEssential COMEssential XML: Beyond MarkUpEffective COM: 50 Ways to Improve Your COM and MTS-based Applications, with Keith Brown, Tim Ewald and Chris Sells*Full QuoteExplanation: too much functionality in a framework will cause unnecessary complexity. It will lead person A solve a problem this way and person B to solve the same problem a different way. It's a bit like grammar. If the same expression can be constructed in too many different ways it will most likely be too confusing to use efficiently. Code is not only there to solve a problem but also to communicate between different programmers how something has been done.

    Bio *Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/

    **Nitin Borwankar worked at Ingres and Sybase in the early nineties, went independent and became one of the very few people doing database work on the web in 1994,using SybPerl and OraPerl (there was no Java then). He first used Linux on a 486/33 with 16 Meg RAM when Linux was at v 0.99. In those days he had a dedicated FrameRelay connection to his home at 64kb which was blazingly fast compared to the 9.6K dialup modems of the time.

    Next was early Java in 1995 and in 1997 he created the first demo of EJB for Sun when the spec was at v 0.5. After doing consulting work in J2EE and Java on the web,

    Over the next 6 -7 years, he rode out the bubble and now focuses on database issues underlying web 2.0 applications. He blogs about this at tagschema.com and often writes for GigaOm.com on database issues. He does strategic consulting to startups and enterprises, often jumping in and doing early prototyping, design work and development. His clients have included VC and financial services companies, major technology companies and small medium businesses. His current interests are in data warehousing, distributed application design using infrastructure like that provided by Amazon Web Services and issues of data portability and data ownership created by social networking. He has recently been invited to join the Data Portability Initiative. He has always aspired to add "UI guy" to his resume but that hasn't happened yet. To him AJAX is more familiar as a cleaning agent.*Wikipedia.org: http://en.wikipedia.org/wiki/Gartner's_Hype_Cycle

    A hype cycle is a graphic representation of the maturity, adoption and business application of specific technologies. The term was coined by Gartner[citation needed], an analyst/research house, based in the United States, that provides opinions, advice and data on the global information technology industry.Since 1995, Gartner has used hype cycles to characterize the over-enthusiasm or "hype" and subsequent disappointment that typically happens with the introduction of new technologies. Hype cycles also show how and when technologies move beyond the hype, offer practical benefits and become widely accepted. According to Gartner, hype cycles aim to separate the hype from the reality, and enable CIOs and CEOs to decide whether or not a particular technology is ready for adoption. A longer-term historical perspective on such cycles can be found in the research of the economist Carlota Perez.A hype cycle in Gartner's interpretation comprises 5 steps:1."Technology Trigger" The first phase of a hype cycle is the "technology trigger" or breakthrough, product launch or other event that generates significant press and interest.2."Peak of Inflated Expectations" In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.3."Trough of Disillusionment" Technologies enter the "trough of disillusionment" because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.4."Slope of Enlightenment" Although the press may have stopped covering the technology, some businesses continue through the "slope of enlightenment" and experiment to understand the benefits and practical application of the technology.5."Plateau of Productivity" A technology reaches the "plateau of productivity" as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.*Source: Internetactu.nethttp://www.internetactu.net/2006/08/25/le-cycle-dappropriation-des-technologies-emergentes-2006-du-gartner/* Member of The A-Team, Server Technologies, Oracle Corporation. Formerly Chief Architect at IQNavigator (2001-2005). Formerly leader of the AdvancedApplicationArchitectureTeam at GemStone Systems Inc. (1999-2000). Formerly Director of Development at SynXis? Corporation (1996-1999).

    Contributor to MartinFowler's PatternsOfEnterpriseApplicationArchitecture. Contributor to FloydMarinescu's EjbDesignPatternsBook. Member of Rally Software Development Corporation's Technical Advisory Board - http://www.rallydev.com/technical_advisory_board.jsp.**Bio:Don Box is a software architect currently working at Microsoft.Along with Bob Atkinson, Mohsen Al-Ghosein, and Dave Winer, Don was of the original four designers of SOAP, a basic messaging layer for web services.He currently works on Brad Lovering's team working on model-driven runtime and tool support at Microsoft. Prior to that, Don was an architect on Windows Communication Foundation (formerly known as Indigo) and related technologies.Before joining Microsoft, Don was a contributing editor and columnist at Microsoft Systems Journal, which later became MSDN Magazine. Don was also a conspicuous figure in the Component Object Model (COM) community, where he coined the phrase "COM is love." He is also a series editor for Addison Wesley where he launched two successful series targeting the Microsoft developer audience.

    BooksEssential .NET, Volume I: The Common Language Runtime, with Chris SellsEssential COMEssential XML: Beyond MarkUpEffective COM: 50 Ways to Improve Your COM and MTS-based Applications, with Keith Brown, Tim Ewald and Chris Sells

    **Bio:Jeremy Meyer is currently a Principal Consultant for Borland in the UK. He has a 4 year degree in computer science followed by 18 years experience as a programmer and architect as corperate developer, consultant and trainer. Jeremy has been an associate of Bruce Eckel for years and has made some contributions to Thinking in Java over the years.

    Quote as explained by Rickard Oberg

    Ah, this is a great one, which I agree with!The point is, I think, that if you make a reusable thing X, and some other developer wants to use it, there's a lot of things that needs to be communicated for it to be re-used. It's not enough for X to just exist. It has to be described, put into context, the one who makes it has to imagine to some extent the different circumstances it can be used in, and then make it as easy as possible for others to use. None of this is related to programming, as in writing code, but rather to people-2-people communication, and education.Different architectures can make reuse easier or harder, but even an architecture with perfect mechanisms for reuse will not enable reuse if this people-"problem" is not understood and dealt with. Otherwise people will keep recreating the wheel over and over again, simply because they don't know of X or understand how to use it./Rickard**Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/

    * Member of The A-Team, Server Technologies, Oracle Corporation. Formerly Chief Architect at IQNavigator (2001-2005). Formerly leader of the AdvancedApplicationArchitectureTeam at GemStone Systems Inc. (1999-2000). Formerly Director of Development at SynXis? Corporation (1996-1999).

    Contributor to MartinFowler's PatternsOfEnterpriseApplicationArchitecture. Contributor to FloydMarinescu's EjbDesignPatternsBook. Member of Rally Software Development Corporation's Technical Advisory Board - http://www.rallydev.com/technical_advisory_board.jsp.

    *Nitin Borwankar worked at Ingres and Sybase in the early nineties, went independent and became one of the very few people doing database work on the web in 1994,using SybPerl and OraPerl (there was no Java then). He first used Linux on a 486/33 with 16 Meg RAM when Linux was at v 0.99. In those days he had a dedicated FrameRelay connection to his home at 64kb which was blazingly fast compared to the 9.6K dialup modems of the time.

    Next was early Java in 1995 and in 1997 he created the first demo of EJB for Sun when the spec was at v 0.5. After doing consulting work in J2EE and Java on the web,

    Over the next 6 -7 years, he rode out the bubble and now focuses on database issues underlying web 2.0 applications. He blogs about this at tagschema.com and often writes for GigaOm.com on database issues. He does strategic consulting to startups and enterprises, often jumping in and doing early prototyping, design work and development. His clients have included VC and financial services companies, major technology companies and small medium businesses. His current interests are in data warehousing, distributed application design using infrastructure like that provided by Amazon Web Services and issues of data portability and data ownership created by social networking. He has recently been invited to join the Data Portability Initiative. He has always aspired to add "UI guy" to his resume but that hasn't happened yet. To him AJAX is more familiar as a cleaning agent.

    **Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/

    *Bio:Rebecca Wirfs-Brock is an author and consultant in object-oriented programming, the founder of the information technology consulting firm Wirfs-Brock Associates, and inventor of Responsibility Driven Design, the Design Columnist for IEEE software. She is a proponent of CRC cards (as part of the RDD design process), and, as she put it, the person who unwittingly spurred others to coin -Driven approaches.

    Books

    Designing Object-Oriented Software, with Brian Wilkerson and Lauren Wiener, Prentice-Hall, 1990, ISBN 0-13-629825-7

    Object Design: Roles, Responsibilities, and Collaborations, Addisson-Wesley, 2002, ISBN 0-201-37943-0

    **Bio:Barry Hawkins is an independent consultant based in Atlanta, Georgia with over 13 years of software development experience. His company, All Things Computed, focuses on coaching and mentoring clients in the adoption of Agile software development practices and Domain-Driven Design. His current interests are the trend of dynamic language adoption within enterprise IT practices, the Python ecosystem, and managing enterprise-level complexity in dynamic languages.

    **Bio:Don Box is a software architect currently working at Microsoft.Along with Bob Atkinson, Mohsen Al-Ghosein, and Dave Winer, Don was of the original four designers of SOAP, a basic messaging layer for web services.He currently works on Brad Lovering's team working on model-driven runtime and tool support at Microsoft. Prior to that, Don was an architect on Windows Communication Foundation (formerly known as Indigo) and related technologies.Before joining Microsoft, Don was a contributing editor and columnist at Microsoft Systems Journal, which later became MSDN Magazine. Don was also a conspicuous figure in the Component Object Model (COM) community, where he coined the phrase "COM is love." He is also a series editor for Addison Wesley where he launched two successful series targeting the Microsoft developer audience.

    BooksEssential .NET, Volume I: The Common Language Runtime, with Chris SellsEssential COMEssential XML: Beyond MarkUpEffective COM: 50 Ways to Improve Your COM and MTS-based Applications, with Keith Brown, Tim Ewald and Chris Sells

    **Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/

    *Nitin Borwankar worked at Ingres and Sybase in the early nineties, went independent and became one of the very few people doing database work on the web in 1994,using SybPerl and OraPerl (there was no Java then). He first used Linux on a 486/33 with 16 Meg RAM when Linux was at v 0.99. In those days he had a dedicated FrameRelay connection to his home at 64kb which was blazingly fast compared to the 9.6K dialup modems of the time.

    Next was early Java in 1995 and in 1997 he created the first demo of EJB for Sun when the spec was at v 0.5. After doing consulting work in J2EE and Java on the web,

    Over the next 6 -7 years, he rode out the bubble and now focuses on database issues underlying web 2.0 applications. He blogs about this at tagschema.com and often writes for GigaOm.com on database issues. He does strategic consulting to startups and enterprises, often jumping in and doing early prototyping, design work and development. His clients have included VC and financial services companies, major technology companies and small medium businesses. His current interests are in data warehousing, distributed application design using infrastructure like that provided by Amazon Web Services and issues of data portability and data ownership created by social networking. He has recently been invited to join the Data Portability Initiative. He has always aspired to add "UI guy" to his resume but that hasn't happened yet. To him AJAX is more familiar as a cleaning agent.

    *Full Quote:Creating great enterprise software isn't a matter of intellect as much as wisdom and tenacity -- the ability to see the similarity between one past experience (particularly a failure) and some aspect of your current context and thus avoid costly downtime, or security problems, or concurrency issues (etc.) is often more beneficial to the larger organization and to customers than is your technical vision.

    Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    **Philosopher in Meditation by Rembrandt*Bio:Luke is a recognized expert on agile product management of software products and a former senior software product manager at four companies. He is also the author of three books and numerous articles on software product management. He is also a frequent speaker at software and other industry events.Before founding Enthiosys in 2003, Luke was vice president of business development in the U.S. for Aladdin Knowledge Systems; vice president of engineering and product development at Aurigin Systems Inc.; education technical director at ObjectSpace Inc.; and vice president of systems engineering at EDS Fleet Services.Lukes counsel is sought far and wide. He is currently a member of the Agile Alliance, having been involved for more than a decade in the Agile community. He has been a featured presenter at numerous conferences including the Software Development Best Practices 2006 and 2007 conferences, The Spring Experience, and The Better Software Conference & Expo. He has also been a guest lecturer at the University of California at Berkeleys School of Information. He is a member of the Product Development and Management Association (PDMA), the Association for Computing Machinery (ACM), and the IEEE.

    BooksInnovation games: creating breakthrough products through collaborativeplayThe toughest part of innovation? Accurately predicting what customers want, need, and will pay for. Even if you ask them, they often cant explain what they want. Now, theres a breakthrough solution: Innovation Games: Creating Breakthrough Products Through Collaborative Play...

    Beyond software architecture: creating and sustaining winningsolutionsAt last, a book that provides the software engineering community with a clearer understanding of the business value of software architecture. There are currently a significant number of books on creating, documenting, and implementing software architecture, but precious few resources have addressed how to build a software architecture that aligns with a customers overall business goals...

    Journey of the software professional: the sociology of softwaredevelopmentLuke Hohmanns first book is for programmers, developers, software managers, students, and anyone involved in the software created on process...

    Find out more about Luke Hohmann athttp://www.enthiosys.com/about-us/our-people/*Rebecca Wirfs-Brock is an author and consultant in object-oriented programming, the founder of the information technology consulting firm Wirfs-Brock Associates, and inventor of Responsibility Driven Design, the Design Columnist for IEEE software. She is a proponent of CRC cards (as part of the RDD design process), and, as she put it, the person who unwittingly spurred others to coin -Driven approaches.

    Designing Object-Oriented Software, with Brian Wilkerson and Lauren Wiener, Prentice-Hall, 1990, ISBN 0-13-629825-7

    Object Design: Roles, Responsibilities, and Collaborations, Addisson-Wesley, 2002, ISBN 0-201-37943-0

    *Nitin Borwankar worked at Ingres and Sybase in the early nineties, went independent and became one of the very few people doing database work on the web in 1994,using SybPerl and OraPerl (there was no Java then). He first used Linux on a 486/33 with 16 Meg RAM when Linux was at v 0.99. In those days he had a dedicated FrameRelay connection to his home at 64kb which was blazingly fast compared to the 9.6K dialup modems of the time.

    Next was early Java in 1995 and in 1997 he created the first demo of EJB for Sun when the spec was at v 0.5. After doing consulting work in J2EE and Java on the web,

    Over the next 6 -7 years, he rode out the bubble and now focuses on database issues underlying web 2.0 applications. He blogs about this at tagschema.com and often writes for GigaOm.com on database issues. He does strategic consulting to startups and enterprises, often jumping in and doing early prototyping, design work and development. His clients have included VC and financial services companies, major technology companies and small medium businesses. His current interests are in data warehousing, distributed application design using infrastructure like that provided by Amazon Web Services and issues of data portability and data ownership created by social networking. He has recently been invited to join the Data Portability Initiative. He has always aspired to add "UI guy" to his resume but that hasn't happened yet. To him AJAX is more familiar as a cleaning agent.

    *Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Bio:Sean Neville was a a Principal Scientists at Adobe credited is the co-creator of the Flex platform at Macromedia. Sean Neville also created Adobes Livecycle Data Services. Prior to Flex, he created other Flash products for J2EE, .NET, and native platforms (Win32 and Mac OS), worked on Flash player networking, sat on the JCP SE/EE Executive Committee for Macromedia as well as several expert groups, and was the architect of Macromedias JRun, the first commercial Java servlet engine and eventually a J2EE server. Sean Neville left Adobe to start a new venture called Brightcove with Jeremy Allaire. He has since left Brightcove and is now working in venture funding.

    *Bio:Barry Hawkins is an independent consultant based in Atlanta, Georgia with over 13 years of software development experience. His company, All Things Computed, focuses on coaching and mentoring clients in the adoption of Agile software development practices and Domain-Driven Design. His current interests are the trend of dynamic language adoption within enterprise IT practices, the Python ecosystem, and managing enterprise-level complexity in dynamic languages. *