O’Reilly Webcast: 10 Things Every Software Architect Should Know

Leave a comment

Advertisements

Oracle JDeveloper 11g — Online Demonstrations

Leave a comment

Oracle JDeveloper 11g — Online Demonstrations

View the online demonstrations below to see JDeveloper in action! All you need to watch the demos is your web browser with flash plug-in and a sound card. You can use the playback bar at the bottom of each demo to control the speed and flow of the demo. To maximize your viewing area press F11 in your browser.

General IDE

 Oracle JDeveloper Development Experience
 Development Lifecycle with JDeveloper 11 g
 The Java Code Editor Features
 Updated SubVersion Support
 UML Design with Oracle JDeveloper
 Developing Extensions for Oracle JDeveloper

Java EE 5.0 Development

 Developing EJB/JPA Applications with Oracle JDeveloper 11g
 JSF Development With JDeveloper

Rich Internet Applications (RIA) with JSF

 Oracle ADF Faces Rich Client Components Quick Overview
 ADF Faces Rich Client Runtime Capabilities
 Oracle ADF Data Visualizations: Graph Interactivity
 Oracle ADF Data Visualizations: Maps, Gauges and Pivot Tables
 Oracle ADF Data Visualizations: The Hierarchical Viewer New
 ADF Faces Rich Client Development Experience
 ADF Data Visualization : Maps, Gauges and Pivot Table – Development Experience

Advanced JSF Development

 Oracle ADF Taskflows – Extending the JSF Controller
 ADF Declarative Components – Reusable JSF Components

Web Services Development

 Web Services Development in Oracle JDeveloper
 WSDL Editor New Features New
 Web Service Data Control Development with Oracle JDeveloper

Oracle Application Development Framework – Oracle ADF

 Oracle Application Development Framework Overview
 Swing Development with Oracle ADF
 New & enhanced declarative features in Oracle ADF Business Components
 Oracle ADF Mobile
 Oracle ADF Desktop Integration New
 Declarative Application Customization – MDS New
 Integrating Oracle Help with your ADF Applications New

Oracle ADF and Oracle SOA Integration

 Creating SDO from ADF Business Components New
 Consuming ADF Business Components SDO in Composite Applications New
 Creating ADF User Interfaces for Composite Applications New
 Integrating ADF with Human TaskFlows New

Database Development

 Database Development using Templates
 Database Reporting New

Oracle Team Productivity Center

 Team Productivity Center Overview New
 Working with Work Items New
 

Oracle JDeveloper 10g Online Demos Archives

Oracle JDeveloper 11g — Online Demonstrations

View the online demonstrations below to see JDeveloper in action! All you need to watch the demos is your web browser with flash plug-in and a sound card. You can use the playback bar at the bottom of each demo to control the speed and flow of the demo. To maximize your viewing area press F11 in your browser.

General IDE

 Oracle JDeveloper Development Experience
 Development Lifecycle with JDeveloper 11 g
 The Java Code Editor Features
 Updated SubVersion Support
 UML Design with Oracle JDeveloper
 Developing Extensions for Oracle JDeveloper

Java EE 5.0 Development

 Developing EJB/JPA Applications with Oracle JDeveloper 11g
 JSF Development With JDeveloper

Rich Internet Applications (RIA) with JSF

 Oracle ADF Faces Rich Client Components Quick Overview
 ADF Faces Rich Client Runtime Capabilities
 Oracle ADF Data Visualizations: Graph Interactivity
 Oracle ADF Data Visualizations: Maps, Gauges and Pivot Tables
 Oracle ADF Data Visualizations: The Hierarchical Viewer New
 ADF Faces Rich Client Development Experience
 ADF Data Visualization : Maps, Gauges and Pivot Table – Development Experience

Advanced JSF Development

 Oracle ADF Taskflows – Extending the JSF Controller
 ADF Declarative Components – Reusable JSF Components

Web Services Development

 Web Services Development in Oracle JDeveloper
 WSDL Editor New Features New
 Web Service Data Control Development with Oracle JDeveloper

Oracle Application Development Framework – Oracle ADF

 Oracle Application Development Framework Overview
 Swing Development with Oracle ADF
 New & enhanced declarative features in Oracle ADF Business Components
 Oracle ADF Mobile
 Oracle ADF Desktop Integration New
 Declarative Application Customization – MDS New
 Integrating Oracle Help with your ADF Applications New

Oracle ADF and Oracle SOA Integration

 Creating SDO from ADF Business Components New
 Consuming ADF Business Components SDO in Composite Applications New
 Creating ADF User Interfaces for Composite Applications New
 Integrating ADF with Human TaskFlows New

Database Development

 Database Development using Templates
 Database Reporting New

Oracle Team Productivity Center

 Team Productivity Center Overview New
 Working with Work Items New
 

Oracle JDeveloper 10g Online Demos Archives

Source: http://www.oracle.com/technetwork/developer-tools/jdev/viewlet-097827.html

Philippe Kruchten offers a meditation on the role of the software architect based on an ancient Chinese text – The Tao of the Software Architect

Leave a comment

This is a very liberal reading of Lao-Tsu’s Tao Te Ching for the use of software architects, based on various French and English translations. The numbers refer to the original tablets, shown at right.

Scroll 12The architect observes the world
but trusts his inner vision.
He allows things to come and go.
His heart is open as the sky. (12)

The architect doesn’t talk, she acts.
When this is done,
the team says, “Amazing:
Scroll 17we did it, all by ourselves!” (17)

When a great architect leads, the team
is hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst, one who is despised. (17)

Scroll 27A good traveler has no fixed plans
and is not intent upon arriving.
A good artist lets her intuition
lead her wherever it wants.
A good scientist has freed herself of concepts
and keeps her mind open to what is.
Thus the architect is available to everyone
and rejects no one.
Scroll 36She is ready to use all situations
and does not waste anything.
This is called embodying the light. (27)

If you want to shrink something,
you must first allow it to expand.
If you want to get rid of something,
you must first allow it to flourish.
Scroll 38If you want to take something,
you must first allow it to be given.
This is called the subtle perception
of the way things are.
The soft overcomes the hard.
The slow overcomes the fast.
Let your workings remain a mystery.
Just show people the results. (36)

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos. (38)

Scroll 45The architect concerns himself
with the depth and not the surface,
with the fruit and not the flower. (38)

The architect allows things to happen.
She shapes events as they come.
She steps out of the way
and lets the design speak for itself. (45)

Scroll 50The architect gives himself up
to whatever the moment brings.
He knows that he is going to leave,
and he has nothing left to hold on to:
no illusions, no resistance in his mind.
He holds nothing back from the project,
therefore is ready for departure,
as a man is ready for sleep
Scroll 53after a good day’s work. (50)

The great way is easy,
yet programmers prefer the side paths.
Be aware when things are out of balance.
Remain centered within the design. (53)

The architect’s power is like this.
Scroll 55She lets all things come and go
effortlessly, without desire.
She never expects results;
thus she is never disappointed.
She is never disappointed;
thus her spirit never grows old. (55)

Those who know don’t talk.
Scroll 56Those who talk don’t know. (56)

Alternate:

Those who do not have a clue are still debating about the process.
Those who know just do it. (56)

Scroll 58The architect is content
to serve as an example
and not to impose his will.
He is pointed but doesn’t pierce.
Straightforward, but supple.
Radiant, but easy on the eyes. (58)

If you want to be a great leader,
stop trying to control.
Let go of fixed plans and concepts and
Scroll 57the team will govern itself.
The more prohibitions you have,
the less disciplined the team will be.
The more you coerce,
the less secure the team will be.
The more external help you call,
the less self-reliant the team will be. (57)

 

About the author

Philippe KruchtenPhilippe Kruchten is former Director and General Manager of the IBM Rational Software Process Business Unit, in charge of the Rational Unified Process (RUP). He worked with Rational for 13 years, in various functions and places: France, Sweden, US, and Vancouver, Canada.

Philippe’s main interests right now, besides software architecture and design, are software engineering and the development process. He is campaigning, in Canada, for the concept of state-licensed professional software engineers.

Source: http://www.ibm.com/developerworks/rational/library/4032.html

Many architects come from the ranks of good developers, but not every good developer wants to be an architect, nor are all of them suited for the role. Whether you’re a developer contemplating a career shift or a manager looking for suitable candidates for an architectural responsibility, it’s important to have a well-informed perspective on this transition. This article discusses the journey from implementation specialization to architecture – The professional architect, Part 1: How developers become architects

Leave a comment

When you look for a good musical conductor, you start by looking for a good musician. But not every good musician makes a good conductor. The situation is similar in the professional development of architects. More and more IT organizations are understanding the importance of sound software architecture, and the architect profession is rapidly emerging as a separate discipline within IT. This presents some fresh challenges to management as they look to recruit architects from a fairly small labor pool. Even when Human Resources finds candidates, screening experience is more limited than with other disciplines. The fastest way over these hurdles is to understand that most good architects are also good developers, so probably the first place to look for architect talent is among the ranks of regular developers. Recruiters can use this insight when screening candidates, whether internal or external. However, tapping this resource can be tricky because few good developers have the characteristics of or the desire to become architects.

This article outlines what it takes for a developer to become an architect. I’ll present the perspective of a developer who might be considering such a move, as well as that of a manager assessing developers for such a transition. I’ll also provide a series of factors to consider when making these decisions.

Personal characteristics

The liaison between software development teams and management has always been a sticking point in IT. Both groups tend to think about a given problem in fundamentally different ways. A lot of science addresses how project managers should track and interpret the progress and issues of developers. But still breakdown in communication is very common and is a leading cause of project failure. A good architect is the most effective known cure for this problem. An architect’s primary responsibility is to provide shared media for communication between developers and project managers. They are responsible for fitting business rules and requirements with engineering practices and limitations to ensure success. Following are some of the key traits of a successful architect.

Willingness and ability to communicate: The most valuable principle when identifying an architect among developers is effective communication. You want to look for skilled and experienced developers who have a history of taking the initiative to communicate with business interests in projects. Architects often have to anticipate gaps in understanding before they can contribute. They have to be willing to go out on a limb to ensure a meeting of the technical and business minds. They don’t have to schedule and coordinate exchanges; this is still generally the job of a project manager. Their task is to determine the best tools and artifacts for expressing the design of a system in a way that facilitates an effective exchange. They must be able to sense when current methods are falling short and a new approach is needed. Writing skills are also important, as are drafting skills, or the ability to use diagramming or charting software.

Experience negotiating details: An architect often has to lead discussions of technical compromises for systems development. Conflicting priorities might involve practical limitations, risk avoidance, or possibly differences in requirements among various business groups. A good architect can efficiently assess the technical possibilities and chart a course for development that addresses various interests and limitations without losing the essential value of the project. This ties into communications skills discussed previously, but also taps into the architect’s technical ability. A good architect candidate would be a developer who often helps steer contentious discussions toward new ideas, and doesn’t become entrenched in one position.

Self-starter; motivated to solve design problems: An architect’s day-to-day goals are often unclear. Many developers simply look at a functional specification to carve out a task list. An architect is usually the one providing these developers the structure required to maximize efficiency. A good candidate takes the initiative not only in communicating, but also in anticipating and tackling design issues — usually without any specific directive. A developer who stays busy and engaged in the project, regardless of assigned responsibility, has an opportunity to shine among his peers.

Abstract thinking and analysis: Architects must be able to take a vaguely expressed concept and turn it into a project artifact that can be appreciated by the interested parties. They must able to appreciate abstract concepts and to communicate them in concrete terms. Good candidates among developers are often called upon, or take it upon themselves, to explain confusing issues in the development life cycle. They are quick to assess ideas and direct them into practical suggestions for moving forward.

Developers often are mathematically strong, whereas good architects tend to be stronger verbally. An “engineering mindset,” often ascribed to developers by managers, is an interesting prism through which to assess architects. Architects should have strong technical problem-solving skills, but they must also be able to grasp the bigger picture of how the people involved interact with technology. This requires a form of abstract thinking (beyond the bits and bytes of code) that can be difficult to master.

I tend to avoid elitism about what level of formal education is required to groom a good developer. I have seen amazing developers who are high-school drop-outs. However, when it comes to architecture, my personal experience as well as my appreciation of the required abilities makes me believe strongly that a good architect usually has attained at least a challenging baccalaureate degree.

Tracing the life cycle

Good architects generally have gained experience at organizations with a well-defined software development life cycle (SDLC). Architects must understand the most important operating procedures of their profession. This does not necessarily mean, for example, working at a high Capability Maturity Model (CMM) level. A good architect can come from an organization that uses the Extreme Programming (XP) approach of multiple small iterations of the SDLC. It is important to be aware of traditional software development practices, such as Michael A. Jackson’s methods: Jackson Structured Programming (JSP) and Jackson System Development (JSD) (see Resources). The study of Jackson is as important to an architect’s professional growth as the study of Donald Knuth is to a programmer’s. An architect can be partial to any of the classic and long-tested software systems development methodologies.

The SDLC can also form a useful agenda for assessing the suitability of an architect. Each SDLC stage has characteristics that provide clues. There are many small variants in the SDLC, but in this section I use a common basis for almost all methodologies. The following list details the SDLC stages and outlines the traits of a good architect candidate for each stage.

Analysis: During analysis, a good architect engages with nontechnical interests to understand requirements and the environment in which the development will occur. The architect brings extensive software experience to the task of risk assessment. Look for a developer with proven experience helping business understand what the technical staff needs to interpret requirements properly. And look for a developer who has anticipated issues at the early stages of development.

Design: During high-level design, a good architect gathers the abstract elements of the problem space and communicates them so the development team can draft schematics of the system to be developed. Architects lead the careful mapping of requirements to features in the resulting systems architecture. They tend to take a less central role during detailed design, but are still needed to vet the elements of particular modules against the imperatives of the system as a whole. Look for a developer who is good at getting the team to anticipate the implications of design decisions on the finished system. Also look for a developer who is good at determining the best artifacts for communicating design to technical and nontechnical audiences.

Implementation: During implementation, architects guide the project to ensure that it stays true to the systems architecture. They are the front line in assessing technical change requests, and they determine how the design can best be adapted to accommodate such requests. The architect also stays in close touch with the developers’ progress and especially tracks the status of integration points between modules in the system. Look for a developer who often leads discussions, bridging multiple subsystems. Also look for a developer to whom the project manager can turn for quick assessment of risks associated with changes and emerging issues.

Testing: The architect directs systems-integration and user-acceptance testing and leads the assessment of ongoing test results for accurate communication of progress. Look for a developer who understands failure modes and is good at translating the results of test review into action plans.

Maintenance: During maintenance, the architect will lead discussions about systems integration. Whether accommodating IT infrastructure issues, or ensuring technical cooperation between departments, the architect must understand the application completely, must quickly learn the architecture of sister applications, and must communicate integration points and risks effectively. Look for a developer who has systems-integration experience and who has demonstrated rapid mastery of the big picture. Systems integration is a unique task.


Back to top

Advice for grooming architects

Some organizations groom architects more effectively than others. Fostering an environment that encourages the evolution of developers into architects can be a sound strategy, considering the difficulty of recruiting such a new specialty. But it is important to avoid penalizing developers who are neither willing nor suited to this path. An organization should create multiple career tracks for developers, including those who prefer to remain developers. Senior developers are indispensable to the architect. They can implement the most critical modules in the system. And through code review and test support for other developers, they help ensure overall software quality, without which even the best architecture is useless.

Organizations should institute personnel-review procedures that encourage developers to consider their career goals, including architecture as an option. Managers should be encouraged to look for architectural talent among their staff. Mentoring programs should be implemented that let architects work with developers who want to become architects. Developers should be encouraged to participate in the professional world by joining associations, writing articles, and attending conferences. Participating in this way helps developers understand systems from a new perspective and helps them better communicate that understanding. It can also seed important, innovative ideas that improve productivity.


Back to top

Conclusion

Once a developer takes a step on the path to architectural expertise, many resources are available to help, including many from IBM. Sometimes the hardest part of the journey is taking the first step, and this article provides some clues and cues managers and developers can use to assess who should be encouraged to become an architect.

 

Resources

Learn

Get products and technologies

  • Build your next development project with IBM trial software, available for download directly from developerWorks.

Discuss

About the author

Photo of Uche OgbujiUche Ogbuji is a consultant and co-founder of Fourthought Inc., a software vendor and consultancy specializing in XML solutions for enterprise knowledge management. Fourthought develops 4Suite, an open source platform for XML, RDF, and knowledge-management applications. Mr. Ogbuji is also a lead developer of the Versa RDF query language. He is a computer engineer and writer born in Nigeria, living and working in Boulder, Colorado, USA. You can find more about Mr. Ogbuji at his Weblog Copia.

Source: http://www.ibm.com/developerworks/library/ws-soa-proarch1.html