Index | Prev | Next

Technical Architect Questions & Answer

  1. Can you give me a recent example of your SOA projects? How did you handle security?
  2. What is a SOA and why is it important?
  3. How do you define a successful SOA?
  4. A successful SOA implementation requires that an organization substantially transform their process to move from a traditional function-oriented, built-to-last, and long-running development cycle to a process-oriented, built-to-change, and incremental build-and-deploy process. Traditional development, in general, is aligned to application silos, is tightly coupled, and is structured using components and objects as building blocks. SOA development presents orchestrated solutions that are loosely coupled, using services as their building blocks. It's important to recognize the differences and establish a process to support the transformation

  5. What is the difference between services and components?
  6. Services are logical grouping of components to achieve business functionality. Components are implementation approaches to make a service. The components can be in JAVA, C#, C++ but the services will be exposed in a general format like Web Services.

  7. What SOA design patterns have you used in the past?
  8. What design principles do you use when architecting SOA services?
  9. How can you achieve loose coupling of services?
  10. As you know design patterns describe recurring solutions to common problems in software design. And recognizing and implementing these patterns is an essential part of successful Service Oriented Design. Below are 5 SOA design patterns:

    1. Multichannel Applications
    2. Composite Applications
    3. Business Process Orchestration
    4. Service Oriented Enterprise
    5. Federated SOA

    Multichannel Application SOA is a perfect fit for multichannel applications. This pattern separates the back-end business logic from the front-end logic and delivers full application functionality to a maximum number of users from various channels in a minimal amount of time while reusing the same exposed services.

    Strategic Planning Assumption: By 2008, more than 66% of new midsize and large interactive applications will be designed to support multichannel access, up from less than 33% in 2007.

    Composite Applications Services used in composite applications may be new service implementations, fragments of old applications that were adapted and wrapped, or combinations of the above. Two types of integration technology are essential for effective operation of a composite SOA environment: 1) integration technology behind the service interfaces, helping users wrap and adopt various pre-SOA applications; and 2) integration technology helping users assemble and monitor transactions from services.

    Strategic Planning Assumption: Through 2012, the majority of SOA-style applications will be interactive composite applications.

    Business Process Orchestration Business process management (BPM) suites are the tools devoted to implementing such SOA-based multistep processing flows. The BPEL standard is often used to document the designed metadata flow model. The metadata repository ("meta-database") is used to manage the proceedings of the business process model at runtime. Some steps of the process are implemented by calling SOA services. Other steps require human intervention.

    Strategic Planning Assumption: By 2009, more than 75% of SOA applications will implement some sequencing control outside of code of the service implementations, via external BPM technology.

    Service Oriented Enterprise The SOA-based enterprise model is a step beyond composite applications. Here, all applications are perceived as components of one integrated whole. No new application is created in isolation. Each application is built from reusable components that are available for use not only in their initially intended context, but also by other clients in other contexts. Essentially, the integrated composite enterprise consists not of applications, but rather business components — each an asset of the entire enterprise.

    Strategic Planning Assumption: By 2010, more than 85% of enterprises will have combined their application integration and SOA management tools and organizations.

    Federated SOA The fundamental idea behind federated SOA is to logically split the enterprise into semi-independent SOA domains (for example, reflecting the enterprise organization in terms of subsidiaries, Business Units or departments), each with its own specific SOA infrastructure, governance processes and SOA Center of Excellence. Domains are then federated (that is, integrated — usually, but not necessarily, after the fact — to enable inter-domain sharing of services) through appropriate interoperability infrastructure, governance processes and organizational settings. "SOA federation" is the process of enabling a federated SOA by establishing the proper technical, governance and organizational capabilities.

    Strategic Planning Assumption: Few large organizations are able to establish a singular architectural blueprint for their entire IT. The best practice is to endorse domain independence and allow them to differ in technology and architecture in exchange for agreement to synchronize interoperability protocols and transports. Mergers and acquisitions are clearly candidates for Federated SOA.

  11. What works better top-down or bottom-up service identification?
  12. Top-down would suggest that you analyze your business processes, identifying activities in support of your process that become candidate operations on service specifications

    A Bottom-up approach would suggest that you analyze existing applications and assets to identify those that will are candidates to be "service-ified".

    Top-down - Has the advantage that the services identified throughout the layers of the solution are aligned with the business processes which provided the scope for the solution. It is also attractive from a project management perspective in that the business process under consideration provides a natural project scope for the development effort. However, the major drawback to this approach (and the reason the customer I mentioned earlier got unstuck) is that it becomes harder to ensure that you develop services for reuse (some thoughts on SOA and Reuse) as developers are looking to develop services that support this process rather than ones that will contribute to an enterprise-wide service portfolio.

    Bottom-up - A bottom-up approach has the potential to develop a set service that can support a number of processes, addressing the concern above, as the developers are looking across a broad set of artifacts. The issues here are that where data is the focus of the artifact analysis the tendency is to generate CRUD services (which is bad) or to develop access operations that do not match well the requirements of processes and therefore require business services to make multiple calls into data-management services.

  13. How can services supporting long running processes be scaled effectively?
  14. How can a SOA avoid redundant service logic?
  15. What is the difference between agile and scrum?
  16. Agile and Scrum are terms used in project management. The Agile methodology employs incremental and iterative work cadences that are also called sprints. Scrum, on the other hand is the type of agile approach that is used in software development.
    The Agile methodology is used in project management and it helps project makers to build software applications that are unpredictable in nature. Iterative and incremental work cadences called sprints are used in this methodology. It is basically inspired from traditional sequential model or the waterfall model.
    The benefit of using the Agile methodology is that the direction of the project can be accessed throughout its development cycle. The development is accessed with the help of iterations or sprints. At the end of each sprint, an increment of work is presented by the team developing the project. The focus is mainly on the repetition of work cycles and the product they yield. This is the reason why the agile methodology is also called as incremental and iterative.
    In agile approach, the each step of development such as requirements, analysis, design etc are continually monitored through the lifecycle of the project whereas this not the case with the waterfall model. So by using agile approach, the development teams can steer the project in the right direction.

    Scrum is a type of agile approach that is used in development of software applications. It is just a framework and not a methodology or a full process. It does not provide detailed instructions to what needs to be done rather most of it is dependent on the team that is developing the software. Because the developing the project knows how the problem can be solved that is why much is left on them.
    Cross-functional and self-organizing teams are essential in case of scrum. There is no team leader in this case who will assign tasks to the team members rather the whole team addresses the issues or problems. It is cross-functional in a way that everyone is involved in the project right from the idea to the implementation of the project.
    As it is an agile methodology, it also makes use of series of iterations or sprints. Some of the features are developed as a part of the sprint and at the end of each sprint; the features are completed right from coding, testing and their integration into the product. A demonstration of the functionality is provided to the owner at the end of each sprint so that feedback can be taken which can be helpful for the next sprint.
    The product is the primary object of a scrum project. At the end of each sprint, the system or product is brought to a shippable state by the team members.
  17. Give me an example where you worked with stakeholders to document functional and non-functional requirements. How did you prioritize the requirements?
  18. Requirement that affects the functionality of the system is Functional and if it will be the constrain to the system is Non-Functional.

Index | Prev| Next