Monday, April 03, 2006

Big Upfront Framework design (BUFD)

Recently I have been thinking is it really worth doing Big Upfront Framework Design(BUFD).
I have taken part in designing several frameworks in my past, but never thought(or didnt get a chance) the best phase to design frameworks. It is agreed by default that frameworks are designed upfront before product development begins. Many highly intelligent architects, designers sit together for days and nights without proper sleep and design meta data driven,XML based,database independent frameworks!!!. But if we carefully look into this, upfront framework design is not really agile, and secondly, ROI is also bad.


* Doing Upfront Framework Design(UFD), would force the designers and developers to design application or develop application to fit the framework, rather than steering the development effort in satisfying the customer's requirements.

* UFD, is not profitable to the customer, because frameworks are generally designed to be as generic as possible keeping future requirements in mind, and due to which, customer would be spending money on "future" requirements in the present!!!

In fact I was trying to think can UFD be applied to Project development scenario, where the project's duration is less than a year ???... Now I feel that it does not suit here too. The reason being, any framework design and development would take atleast 3-4 months, and I feel this effort is not worth spending for a shorter duration project !!

Ok, the best possible solution could be:

* Start thinking about framework from the beginning (dont stop yourself), but dont start the design until you pass the inception pase.

* Start laying the foundation from Elaboration phase.

* As the product development progress, design, tweak the framework iteratively.

* The Framework should evolve over a period of time, and at the same time ensure that is "usable" (need not be complete) before construction phase !!

* keep refactoring, evolving and be agile

Sunday, April 02, 2006

Cleared SCEA Part 1 Exam

March 31st 2006: I cleared the Sun Certified Enterprise Architect exam. I was planning to take up this exam from some time, and in the last 3 days I really put some effort and passed the exam with good scores.

I have scored 100% in many of the following objectives, especially the ones that I am passionate about like Design patterns, EJB, Applicability of J2EE, Legacy Connectivity(even though I dont like this subject I know a bit), protocols, messaging.

Exam Objectives

Section 1: Concepts
* Draw UML Diagrams
* Interpret UML diagrams.
* State the effect of encapsulation, inheritance, and use of interfaces on architectural characteristics.

Section 2: Common Architectures
* Recognize the effect on each of the following characteristics of two tier, three tier and multi-tier architectures: scalability maintainability, reliability, availability, extensibility, performance, manageability, and security.
* Recognize the effect of each of the following characteristics on J2EE technology: scalability maintainability, reliability, availability, extensibility, performance, manageability, and security.
* Given an architecture described in terms of network layout, list benefits and potential weaknesses associated with it.

Section 3: Legacy Connectivity
* Distinguish appropriate from inappropriate techniques for providing access to a legacy system from Java code given an outline description of that legacy system

Section 4: Enterprise JavaBeans Technology
* List the required classes/interfaces that must be provided for an EJB technology.
* Distinguish stateful and stateless Session beans.
* Distinguish Session and Entity beans.
* Recognize appropriate uses for Entity, Stateful Session, and Stateless Session beans.
* State benefits and costs of Container Managed Persistence.
* State the transactional behavior in a given scenario for an enterprise bean method with a specified transactional deployment descriptor.
* Given a requirement specification detailing security and flexibility needs, identify architectures that would fulfill those requirements.
* Identify costs and benefits of using an intermediate data-access object between an entity bean and the data resource.

Section 5: Enterprise JavaBeans Container Model
* State the benefits of bean pooling in an EJB container.
* State the benefits of Passivation in an EJB container.
* State the benefit of monitoring of resources in an EJB container.
* Explain how the EJB container does lifecycle management and has the capability to increase scalability.

Section 6: Protocols
* Given a scenario description, distinguish appropriate from inappropriate protocols to implement that scenario.
* Identify a protocol, given a list of some of its features, where the protocol is one of the following: HTTP, HTTPS, IIOP, JRMP.
* Select from a list, common firewall features that might interfere with the normal operation of a given protocol.

Section 7: Applicability of J2EE Technology
* Select from a list those application aspects that are suited to implementation using J2EE.
* Select from a list those application aspects that are suited to implementation using EJB.
* Identify suitable J2EE technologies for the implementation of specified application aspects.

Section 8: Design Patterns
* From a list, select the most appropriate design pattern for a given scenario. Patterns will be limited to those documented in Gamma et al. and named using the names given in that book.
* State the benefits of using design patterns.
* State the name of a design pattern (for example, Gamma) given the UML diagram and/or a brief description of the pattern's functionality.
* Select from a list benefits of a specified design pattern (for example, Gamma).
* Identify the design pattern associated with a specified J2EE feature

Section 9: Messaging
* Identify scenarios that are appropriate to implementation using messaging, EJB, or both.
* List benefits of synchronous and asynchronous messaging.
* Select scenarios from a list that are appropriate to implementation using synchronous and asynchronous messaging.

Section 10: Internationalization
* State three aspects of any application that might need to be varied or customized in different deployment locales.
* Match the following features of the Java 2 platform with descriptions of their functionality, purpose or typical uses: Properties, Locale, ResourceBundle, Unicode, java.text package, InputStreamReader and OutputStreamWriter.

Section 11: Security
* Select from a list security restrictions that Java 2 environments normally impose on applets running in a browser.
* Given an architectural system specification, identify appropriate locations for implementation of specified security features, and select suitable technologies for implementation of those features.