The Architect’s World – Episode 21

Intro

Everybody seems to have a role carved out for an ESA/Solution Architect, with the responsibilities nailed down to a T.. Whenever I pick up the newspaper classifieds, or browse the job sites or analyst reports, or talk to consultants themselves aspiring to move up the value chain. With all the heat generated in the job market, there seems to be a myriad of definitions floating around in organizations of various shapes and sizes. Not to be outdone, head-hunters have put up their own claim to the tag. And some of these interpretations gave me goosebumps. So, not to be left behind, in this blog, I coin my interpretation of the role, a thought for a certification process and a job requirements/responsibilities matrix or a job description for the same. Needless to say, it is an extension of what I have been trying to out forth since the first blog of this series. And then again, 25+ ESA workshops and counting, I did learn a few things about what customers are looking for in this role. The customers did make me a lot wiser and made me shed a few of my pre-conceived notions about this role. So, what does the customer today demand of an ESA/Solution Architect? Let us explore the qualities of a knowledgeable Architect and do a bit of introspection to where we stand. The future looks good and exciting – IF ONLY SAP would formalize this role by certifying the same: (Great minds in SAP are thinking about it)

Need #1: A Business Solution approach:

With an experience of carving business solutions around core R/3, Java applications, legacy or 3rd party software and middleware/businessware, from an integrated standpoint (not standalone), the Solution Architect needs to possess the ability of thinking out-of-the-box in a product/vendor-agnostic manner to ensure the right solution. Many, under the garb of Solution architects, tend to focus on selling user licenses, new service lines and do their bit as the extended sales arm to get the business. Ethically, downing a solution, if it does not address the business need of the customer, in my opinion, is a far greater success story for a solution architect than blindly going ahead with politically correct initiatives. Therefore, it warrants a good understanding of key business processes, at least to a level that helps in understanding the business need right and articulating the vision of the organization at a grass-roots level. Not at as a “white-paper” level talk.

Need #2: The Web Technologies link :

A strong fundamental understanding in at least one of the key technologies like Java/J2ee, .net, ABAP, Middleware, web services/SOA. With hands-on experience being probably much better, this technological exposure must come more from a business solution standpoint with packaged applications, or best-of-breed applications like i2, Ariba Spend Management Suite, or other such packaged solutions addressing e-procurement, e-marketplaces, exchanges, externally/internally hosted solutions for catalog management, corporate intranet solutions, exposure to RUP and other technologies. The reason this becomes so very important for a Solution Architect to know these technologies is to ensure that the extended enterprise becomes of utmost importance while solutioning with business partner interactions. Subject to a high-degree of mis-interpretations, deep expertise in only one of the above mentioned technologies give birth to extremely focused Architects, who can base solutions only around a single platform – which can hurt the customer very badly. A pure horizontal experience with no vertical focus again, makes a myopic consultant.

Need #3: Knowledge of Business Processes :

There is no depth to the level of expertise as to what level a Solution Architect can delve into, it is the breath and depth that matter, with the breadth of expertise taking priority over depth in some cases, and in other – the depth being of more value than breadth. Different strokes for different folks. With SCM being the key, Order-to-cash, procure-to-pay (direct and indirect), demand-to-fulfill, accounting-to-analysis – these processes need to be understood to a level of expertise from a configuration standpoint in core R/3. With a solution being driven on SAP NetWeaver, there is no way a Solution Architect can get away by being an ERP-averse consultant. The ability to understand, articulate, transform and implement these solutions in R/3 with the focus on core modules of FICO, SD,MM, PP and PS would make a sound Solution Architect. Not to be setting the bar too high, but it is not an impossible combination from a horizontal technology standpoint. In fact, the solution would be even better with a tilt more on horizontal skills than vertical skills. After all, there is a thin line of demarcation between a business analyst from the client organization compared to the SI Consultant. Many System Integrators go overboard in calling their “SAP Functional consultants” as “Business consultants” – all to get a top-dollar billing. And this is exactly the situation when things move from ridiculous to sublime.

Need #4: Exposure to surrounding technologies :

A hands-on consultant groomed to become a module lead, Program Manager/Solution Architect handling Programs/Projects of large and medium magnitude would make the best fit for this role. Exposure to a multitude of technologies, packaged applications and hands-on experience only enriches the value of a Solution Architect. Many a times, key architectural decisions are taken by people who have more or less been on the high-end curve or Peter’s principle. One-time consultants, who are completely out-of-touch with business and market trends or technology are sure-fire successes to failed implementations. Not to be confused with a lead implementation consultant, the ESA/Solution Architect must posses the knowledge from a hands-on perspective who can take an outside-in perspective for an SAP NetWeaver program/initiative, be in a position to marry up all existing IT initiatives and suggest the best course of action for an ESA roadmap for an organization spanning at least 5 years is the hallmark of an ESA/Solution Architect. Surrounding enterprise applications skill in various areas of CRM. SCM, B2B, ERP, Middleware, data warehousing and relevant technologies, it helps if you have a good enough understanding of the capabilities of the surrounding application space. Experience in process improvement exercises like IS9000/Six Sigma and the likes only help further in becoming a well-rounded ESA/Solution Architect.

Need #5: Multi-project/multi-client experience :

As an ESA/Solution Architect, one needs to have seen cycles of implementations at various levels, at various stages of implementation, in various technologies and roles. A good understanding of the client organization’s product domain, relevant technologies and development processes – and driven by SAP NetWeaver. Being a technologist, in my opinion, rates much higher in this space, than being a pure business person. But even in the technical area, key activities are much different than those of the developers and the issues are less clearly-defined, mostly with hazy or clashing end-points, and the Architect is to play a critical role in defining the very objectivity of the same. Aligning the organization’s overall objectives from an ESA standpoint using the SAP NetWeaver platform, the initiatives need to be lined up based on priority of the business – from where the funding usually comes in. To take an overall system view, the role demands placing objectively the key initiatives that make up the overall solution/program. And unless, someone has spent enough time in doing multiple roles at all levels, across technological boundaries, with the core expertise zone of SAP, it may not make too much sense. Nothing makes up for implementation experience – good and bad, with different folks in different areas.

Need #6: Soft-skills :

Your solution doesn’t matter if you cannot articulate it well. Who cares if you are God’s gift to mankind when it comes to knowledge, skills and capabilities if you lack the ability to get it across straight and simple with the Customer organization in a politically correct manner? Soft-skills, in my opinion, play a dominant role in packaging this role and providing the optimum level of abstraction between Sales, Architecture and Delivery from an SI standpoint. Contrary to popular belief, this is something that cannot be talked about much – you either have it, or you don’t. It is for you to work on it through professional courses.

Need #7: The Certification process :

If SAP were to make this role an Official one and certify it, here are my ten cents about the certification process:

The SAP Certified ESA/Solution Architect Program must be validated by top industry experts from the industry, consulting firms and SAP Installed base to create a distinguished pool of this variety, especially with SAP NetWeaver product certified consultants being made available a dime a dozen. High standards need to be maintained here – this person must possess a minimum of “X” years of IT experience, with a minimum of 2 years in the role of a Solution Architect. Do not complicate matters by creating levels in the same by creating “Junior” and “Senior” ESA/Solution Architects. This person must possess strong technical and leadership skills and business skills. Differentiating this with other certifications, this pool must go through rigorous rounds of interviews and reviews by a board/panel members, that/who would shape up the SAP NetWeaver product management, IT Veterans, CXOs and key corporate representatives and SAP Installed base evangelists.

This panel/board must measure the ESA/Solution Architect’s success rate in implementations, multiple technologies (as described above) and must evaluate the person’s participation in the Implementation life-cycle while creating business solutions. This is the review/evaluation process for this elite group. A group that customers should look forward to work with to bring standards across the industry and something that would display the seriousness with with SAP and the SI Community is approaching the ESA initiatives and the SAP NetWeaver platform with.

Initial screening must be done by the board before reviewing the applications for the ESA/Solution Architects. SAP must then support these Architects by grooming for a period of say, 15 days, in various areas that the Architect group wants to drive through on the customer community, and finally have the review process to certify this pool of Architects with a round of techniques inclusing case studies, presentations, discussions and voting. The standards need to be high, the rejections should be taken care of in the initial process of screening itself.

Assign a mentor, have the course material – Business and technical which can be used for the review preparation. During this 15-day stint, the ESA/Architects go through a round of sessions, prepare for their review and finally get certified post review by the board. And the same must be driven and designed along-with industry experts and not be driven as yet another methodology course. Treat this nothing short of a finishing school.

Keep the certification in line with PMI and have the review done by the board on a yearly basis to ensure that the pool remains focused along with SAP. Creating streams here of infrastructure and Solution may be a good idea, but not product-driven.

Such a certification process would only help SAP groom the ESA/Solution Architects as Leaders, technologists, consultants and strategists, most importantly, create a pool of certified Solution Architects world-wide who propagate the same message in line with SAP’s statement of direction and are in a position to create value in the industry.

The Job-Matrix :

Please refer other blogs in the series.

Outro:

Of course, there are many other traits required for an ESA/Solution Architect. Some people mistake age as the sole criteria for experience. Both need to be fully functional – the right and left part of the brain. And of course, for an Architect to succeed, the entire SAP Community has a role to play. It is a paradigm shift which needs to happen in the SI community – you cannot put your so-called “senior” resources up as Solution Architects merely because of their Project/Program Management skills and they look old and senior (yes, it is a fact!). Growing old in one corner of the plant, doing a routine job does not make one a Supply Chain specialist. But, it gets worse if the experience is not there. Of course, the lesser the political pressures on the Architect, the better is the solution. Many a times, one sees this role as a corroboration of internal thoughts by a neutral external agent who is to validate the politically correct decision. And it is upto the client Organizations, like Org. A to decide. This is only an idea, an opinion. Your feedback/suggestions are welcome. Probably, you have more ideas to make it better.