I just received the book IT Architecture Toolkit. This is a must read and 5 stars book, considered the “Bible” for architects. Read the review from Amazon:
Enterprise IT architecture made practical–finally!
There’s only one way to maximize legacy infrastructure while integrating new partners, technologies, applications, and data streams: begin with a coherent enterprise architecture. But most approaches to enterprise architecture have been far too complex and theoretical–until now. IT Architecture Toolkit is a breakthrough: a practical, simple, rapid, and complete approach to delivering on the promise of enterprise architecture.
Jane Carbone’s approach has been proven in mid-market and Fortune 500 enterprises alike. Step by step, Carbone shows how to integrate business, architecture, implementation, and all key outputs: for data, applications, technology, and people. Whether you’re an IT leader, architect, planner, or analyst, you’ll learn how to:
- Create strong, auditable links with business drivers
- Model your architecture simply, easily, and quickly
- Translate your models to real, manageable projects.
- Define the value proposition for architecture and establish realistic metrics
- Achieve buy-in throughout your organization
- Manage the “soft” aspects of your architecture initiative, including processes, roles, responsibilities, and organizational structure
Carbone provides a “soup to nuts” collection of methods and examples. Using her exercises, you’ll construct a complete draft architecture for your own business: one that will handle change, opportunity, growth, mergers, downsizing . . . whatever comes your way.
This article is an except from the book “Requirements-Led Project Management : Discovering David’s Slingshot (Hardcover)” by Suzanne Robertson, James Robertson. The text begins with an intesresting comment:
Whenever we make an investment—some stocks, a new car—or do some work, we like to think we get something in return for the money or effort expended. In this chapter, we look at your investment in requirements and what you can expect in return. And though all men may be considered equal, all requirements are not. Some requirements are crucial to the product, while others are gold-plated luxuries. We discuss how business people and requirements analysts can determine how much to invest in requirements, by focusing on the value of requirements to their organization.
“Improved software practices provide returns ranging from 300% to 1900% and average about 500% … The reason for these excep tionally high returns is … improved practices [that] have been avail able for decades, but most organizations aren’t using. Risk of adopting these practices is low; payoff is high.“
—Steve McConnell, Professional Software Development
Link to Article: Since Eclipse’s first release in 2001, it has become a popular environment for Java development. In the period between March 10 and May 11, 2005, users downloaded over 17,000 copies of one of the production SDK releases and over 3,500 copies of one of the stable (milestone) SDK builds on average every day. A vibrant eco-system of developers, plug-in providers, authors, and bloggers has grown up around it. Eclipse has also gained the backing of the key Java vendors including BEA, Borland, IBM, SAP, and Sybase. Developers like Eclipse because it provides a great platform for building Java applications, and companies like it because it unifies their software tools under one open source umbrella.
Here is 7 (seven) good reasons to migrate to Eclipse 3.1?
1) Full support for the new language construtions in J2SE 5.0 (or J2SE 1.5): generics, annotations, enuns, auto boxing, enhanced for loop etc.
2) Fast compilation. Eclipse 3.1 has its own compiler that brings some benefits: besides raise you productivity, we have now smoother debugging and refactoring and a lot of diagnostic warinings.
3) Eclipse 3.1 improves its Ant support by including the latest version of Ant.
4) This version is a lot faster and uses far less memory for common operations, comparing with version 3.0.
5) Ready for large projects: Eclipse Platform team created one consisting of 135 separate projects and 70,000 classes and other resources. Good enough hum?
6) Return of the Java Client: the Rich Client Platform (RCP) is a subset of Eclipse that provides a framework for application development.
7) Over 7,000 enhancements requests and bug reports have been addressed in release 3.1.
This article from JDJ talk about the new “XML Rich-Client Technology”. J2EE is the best for server-side but not so good as .NET is in the client-side. Until now!, according to this proposal. Let’s see the rationale:
Which platform to use Java or .NET? Developers ask this question all the time. Java has been widely adopted because of its overwhelming benefits on the server side, but Java has less to offer on the client side. .NET has made inroads into the enterprise by leveraging its stronger rich-client capabilities. An alternative solution for enterprise-scale Internet application development is the emerging XML-based rich-client technology.
SEI has a good material devoted to to Software Engineering. Stating with the basic question, How do You Define Software Architecture?. This page presents many classical definitions from the most known authors of Software Engineering, as well as the definitions that the comunity around the world submitted to SEI. Another must reading article is that one that defines the Duties of a Software Architecture. Let’s point out some definitions:
- “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. First, architecture defines elements. The architecture embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, an architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. In nearly all modern systems, elements interact with each other by means of interfaces that partition details about an element into public and private parts. Architecture is concerned with the public side of this division; private details of elements—details having to do solely with internal implementation—are not architectural….”
- “An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization—these elements and their interfaces, their collaborations, and their composition (The UML Modeling Language User Guide, Addison-Wesley, 1999).” — Booch, Rumbaugh, Jacobson 1999
- [Lane 90]: Software architecture is the study of the large-scale structure and performance of software systems. Important aspects of a system’s architecture include the division of functions among system modules, the means of communication between modules, and the representation of shared information.
Glen Vanderburg keeps this page with quotes related to Software Design. Below you can read some of them.
- …with proper design, the features come cheaply. This approach is arduous, but continues to succeed — Dennis Ritchie
– The problem with using C++ is that there’s already a strong tendency in the language to require you to know everything before you can do anything. — Larry Wall (father of PERL)
Enterprise Blogs are useful for many reasons:
– Information is always there; it is difficult to search that magic tip that your friend sent you 6 months ago among tons of emails;
- Co-workers and friends can add comments and complement your posts with alternatives, offering a new point of view that you probably never had though before. This is what makes a good discussion;
- Share! Share! Share! “If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas.” — George Bernard Shaw
There are lots of good reasons that would encorage you to promote blog activities among your team members. IBM bets in this new trend: read this article (in Portuguese) or this (in English).
Scott Ambler is one of the best authors of "Agile Development". A good source if the Agile Modeling Site Map, a collection of essays and a general guideline about this methodology. Let’s see what Wikipedia says about Agile Methodology:
Agile software development evolved in the mid 1990s as part of the reaction against "heavyweight" methods, like the Rational Unified Process
(RUP). The processes originated from those methods were seen as bureaucratic, slow, demeaning, and contradicted the ways that software engineers actually work.
Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird (see "The Agile Manifesto," above) and adopted the name "agile methods." Later, some of these people formed the Agile Alliance , a non-profit organization that promotes agile development.
Early agile methods–created prior to 2000–include Scrum (in management), Crystal Clear, Extreme Programming, Adaptive Software Development, and DSDM.
Extreme Programming, while it may not have been the first agile method, unarguably established the popularity of agile methods. Extreme Programming was created by Kent Beck in 1996 as a way to rescue the struggling Chrysler Comprehensive Compensation (C3) project. The methodology was refined by Ron Jeffries‘ full-time coaching and public discussion on Ward Cunningham‘s Portland Pattern Repository wiki . In 2000, Kent Beck published the first book on Extreme Programming . Elements of Extreme Programming appear to be based on Scrum and Ward Cunningham‘s Episodes pattern language.