Role of Development Architect vs Solution Architect

There are a lot of “Architect” titles in the enterprise, mostly used interchangeably. However, there are differences between some of them; at least the Development Architect versus the Solution Architect.

Solution Architecture is a design blue print that satisfies a given enterprise problem and a solution architect needs to apply architectural principles to the solution to create that blue print. This is important because success of any architecture is dependent on its uptake.

That is the core difference between a Development Architect and a Solution Architect – a Development Architect CREATES the architecture and a Solution Architect APPLIES it to solve a problem. It takes a different mind-set and is not just some terminology issue. Having done this role; and working with other solution architects, I like to use this movie analogy…

  • Development Architect is like the movie equipment producer e.g. camera.
  • Solution is the end product — the movie itself.
  • Solution Architect is the Director knowing enough of both to make movies.

One cannot produce blockbuster movies with just technical knowledge of the equipment otherwise every movie technician would be winning Oscars for their directorial ventures. What is needed is a James Cameron who has a broad understanding of the solution – market, audience, story, screenplay, direction, background score, cinematography etc – as well as deep knowledge of the tools – 3D, film formats, sound formats, color coordination, special effects, sync-sound, foley sound effects etc. That is the role of a solution architect – someone who has the deep know-how as well as broader vision of creating an Avatar!

In enterprises, solution architects need to understand the architecture – applications, data models, middleware etc – and how to leverage them to satisfy the solution needs – working with stakeholders, identifying the correct need, negotiating scope etc.

The above does not imply in any way that any one type of architect is more important than another. Even Cameron had to wait more than a decade before the technology became mature enough for his vision, so both types of architects are crucial to the success of the solution – the analogy is just to highlight the differences.

AIA Implementation Resources

While the number of implementation resources available for AIA – Metalink notes, white papers, best practice documents, tips and tricks, tools, templates etc. – are all extremely helpful in implementations, the challenge has been in actually finding this information. Based on popular request, we have put together all these resources on a single page, now available on the Oracle Wiki. Please visit this page for all your implementation needs, and leave a feedback if you find it useful, as well as if you find any information missing that would be helpful if linked to that page.
Link to AIA Implementation Resources on Oracle Wiki

Do I really need AIA?

One of the frequently asked questions from those new to AIA or other canonical object based methodologies, is whether AIA is really needed in their specific SOA project.

In short, it depends.

Now, the longer version. AIA provides a robust platform and framework for business process driven, SOA based enterprise application integrations. If your business process already has a pre-built Process Integration Pack (PIP) available from Oracle for your specific enterprise applications, then it is a no-brainer to use the PIP.

For example, if you are implementing the Order to Cash process with Oracle Siebel CRM as the front-end system and Oracle E-Business Suite as the ERP system, then the Siebel CRM Integration Pack for Oracle Order Management: Order to Cash PIP should definitely be on your shopping list.  Even if the exact applications (or versions) are not a perfect fit i.e. say, you want the CRM integration to PeopleSoft or a legacy application, then you can start with the PIP and replace the Application Business Connector Services (ABCS) from the Oracle E-Business Suite to the other application. Compared to a 100% custom development solution, this provides you with all the benefits of a flexible integration framework and will be faster to implement since one end of the PIP has already been developed.

So the question “Do I really need AIA” only has relevance for business process driven SOA integrations for which there are no pre-packaged PIPs i.e. comparing use of AIA Foundation Pack (FP) vs a custom point-to-point development using Fusion Middleware. Now, the Foundation Pack is built on top of Fusion Middleware, so it must be providing value-add on top of it. I like analogies, so let’s take the following example.

Which is the faster, better way to build a plane?

 

AIA - Building Raw vs with Components

Building Raw vs with Components

I think everyone would agree that having pre-built components, engineered and tested to the specifications of what a plane needs, is a much faster and better way, than to do-it-yourself with basic raw materials, even if you have access to the same tools in both cases. The AIA Foundation Pack provides these pre-built components, that are engineered to the demands of EAI based SOA integrations. It provides the pre-built components such as the Enterprise Business Objects (EBO), the AIA reference architecture and programming model, governance tools (e.g. service repository, integration scenarios) and framework utilities (e.g. error handling, message level testing).

So in the case of an EAI-based SOA integration, the answer is absolutely Yes, you do need AIA!

Now, I know many would argue, “but I am not really building a plane, I just want a one-time, quick, cheap solution, which may never need any enhancements”.  In this case, going the route of direct point to point integration using SOA may suffice, but not without risks.  Once you end up building a passenger train (the cheap, quick solution instead of a plane), which runs on a direct point to point track between SFO and LAX, it becomes next to impossible to later turn it into a plane flying random segments (e.g. NY) with a higher capacity and faster performance. In almost all cases, you would have to re-implement the project to start building a plane.

So the key is to be clear on the business needs and then plan for the right enterprise architecture to implement it. If the business needs a plane, go for AIA. Evaluate the use of native SOA technologies with point to point interfaces, only when it is absolutely clear – at all levels of management – that you are building a train.

Why It’s All Up to AIA

That is the topic of Joshua Greenbaum’s recent blog post during OpenWorld, detailing the reasons why he feels AIA is so important to Oracle.

“I used to think that Fusion Apps (did I say I was impressed with what I saw? So what, it’s worth saying twice) would be the make-or-break development on which would ride the future of the company. But more and more that make-or-break role is falling to AIA. This product, which orchestrates all the different processes across the vast, and disparate, Oracle Applications stack, is the place where the vision of Oracle becomes reality: There is no way for Oracle to pull off rationalizing its massive acquisition strategy without AIA making all the interprocess communications between, say, Glog, Siebel, Oracle Financials and PeopleSoft HR (and SAP, while we’re at it) seamless, easy, and fast. Absent a highly performant AIA middleware layer, Oracle’s dream of cross application process functionality becomes a user nightmare.”

A must-read article.

Six questions to analyze for SOA readiness

One of the AIA partners, Infosys, has published an article on their blog listing the six things a company must know if they are ready for SOA. An interesting read that lists the areas where AIA can help in leveraging the benefits of SOA.