I like the term Technology Adventurer, I think I might actually adopt it for my own use. I would love to take the credit for having come up with it as an idea but alas I saw it as SAP Adventurer as a job title/personal description of a former colleague on LinkedIn. The idea of Technology Adventurer seems so much more alluring than Technology Builder-Breaker although I am sure many of us can take the credit for informally having that title or something akin to it, as part of our profile too.
Lately it seems that the spaces that I have been working in have had a good mix of both technology building and breaking. From leveraging BAPIs to do the same stuff as Winshuttle has historically done with transaction based recordings to bringing unhealthy systems to their knees with pushing the limits on data throughput using transactions, queries and BAPIs. Increasingly, I am finding that my experiences in past lives are still holding out to be quite useful for current business and environment problems. Since the advent of non mainframe solutions the idea of shuttling data around using either FTP, APIs, RFCs and their derivatives has in fact not slowed down at all but in fact increased in velocity and volume of system transacting across almost all industry models. I think the future will continue to see this trend, there really is no reason that it should go away businesses are getting bigger and there are simply more people out there. With all that in mind, the idea that your SAP system needs to be supported by robust infrastructure seems intuitively obvious but unfortunately this assumption is premised on all participants having perfect knowledge and information and in particular it relies on your system architects understanding all the dependencies of your landscape.
There is more to your SAP system than you think
In 2000 when I first started working with SAP one of my engagements was with a company with geographically distributed operations. Telecommunications infrastructure was fragmented, unreliable and relatively low bandwidth and as a consequence we had to come up with imaginative ways to connect a large disconnected potential user community to a centralized SAP system in a consistent and reliable way. Only after exhaustive search, customer references, visits and demonstrations did we eventually determine the network architecture that would work for our environment, it was a composite environment using various technologies. It is important to note that today, with hindsight and knowledge of the potential for mass transacting on any given SAP system directly from the desktop; we probably couldn’t have satisfactorily implemented the network design we ultimately selected. The main reason would likely have been the entirely different shape of data traffic that mass creates and change processes have on a given SAP system. Under such circumstances, with a less robust wide area network we would likely select mass data creation and change by user proxy or terminal services rather than trying to shove the data down a 512kbps satellite link and across a 2Mbps wireless bridge.
The point of my mentioning this example is that even in environments serviced by large scale, highly scalable and robust technologies, the fundamentals of just network design by example, may lead to unexpected outcomes when the playing field attributes change. With a recent customer issue my experiences with packet shaping and prioritization, throttled traffic and shared bandwidth all played into painting a better collective understanding of potential reasons for system performance problems, these were non-specific to SAP but they did speak to the likely sources of performance problems. When something is new, the old assumptions about the environment, the work practices and the infrastructure need to be re-evaluated .
I am not a MS Windows or network engineer, not a BASIS administrator nor a guru in SAP module configuration. I am very much a generalist; however I am fortunate that my past experiences in various roles with a wide array of technologies spanning the full breadth of the OSI model position me at some advantage to at least have an occasional light-bulb moment when trying to help others deconstruct the potential sources for problems that may be being experienced in the field. I guess that this experience makes me into what I think of as an IT Adventurer more than an SAP Adventurer but at least with the SAP prefix it could be saying a little more about where I am concentrating my current efforts. The fundamentals of many technologies haven’t really changed since the introduction of client-server computing but regrettably today the opportunities for individuals to get their feet wet in all aspects of the end-to-end solution seem to be limited. There is heavy pressure on career minded individuals to become specialized and I believe this specialization is potentially detracting from their ability to fully understand the opportunities presented by alternative technologies. College graduates already seem to be being pigeonholed with all the specialization approaches offered in education.
It is not enough to be a BASIS admin with BW
It seems for example, only yesterday that SAP introduced BW which BASIS admins simply took on their shoulders of responsibility and now those BASIS skills are not enough. For example to simply be a BASIS administrator who supports a BW environment, now you have to be a BASIS administrator who lives and breathes BW every day. You have to be able to speak BW-speak to BW developers; A good BASIS admin for BW for example is likely called a BW Basis Admin; someone who can advise on BW Landscape issues, speak to the quirks of the Transport environment, evaluate and understand the BW Security Authorization model, evaluate system performance Issues of Database and BW; do the installation of BW Servers, add-ons, plug-ins and the frontend clients, managing all layers including patches and support packages and keeping them up to date. I don’t see anything in there on networking or operating systems but I guess that’s not their problem that’s the problem of the enterprise architect.
As far as SAP enterprise architects are concerned. I see an increasing trend toward SAP BI Enterprise Architects for example, people who understand the fundamental technology and the components that will make the most cost effective and efficient solution possible for the enterprise but do they understand what they need in the operating systems and networking space? When you look at the SAP Enterprise Architect who evaluates a mass create or change technology for use in a given enterprise for example, it seems obvious that someone who is a former consulting BASIS Administrator, ECC/R-3 Enterprise Architect, PI/XI or ABAP Consultant simply does not have enough experience and comprehension of what would make a good choice of technology combinations. I would even go so far as to argue that this role cannot be achieved successfully by a single individual. More often than not, it requires subject matter experts in a variety of skilled areas to augment the overall enterprise architecture organization, is this really how SAP enterprise architecture is handled? Good enterprise architects are often SAP Adventurers, people who have breadth and some degree of depth, an intimate knowledge of the latest kernel release on the PAM is probably useful but not a prerequisite, a thorough knowledge of the transactions and configuration attributes of the order-to-cash process in SAP may be useful but not fundamental to the role. So what does the role likely require?
In my opinion, good architecting leverages the experiences of the architect together with a clear understanding of the business problem and a willingness to entertain inclusion of SME’s who come with hardware, networking, security, usability, development, change management and system administration expertise. People who have fought the fires, built and broken systems, intentionally and accidentally all bring experiences and skills that help to create a more complete and future focused system architecture. Being a person with more generalized experience probably doesn’t hurt either.
The career rollercoaster
There is a continuing trend of some individuals concerned about their career marketability racing to keep abreast of all the latest and greatest offerings in a particular technology area. Being current is important, but there should also be some anxieties about this trend amongst architects, we need really proficient people in given areas but should these people be THE system architect?
Incredibly deep knowledge in a given field often inhibits that individual’s ability to consider and potentially embrace alternative ways of doing things with technologies and solutions that at first blush are not necessarily obvious candidates for part of a given enterprise solution. Of course I am advocating some degree of generalist (remember career marketability…) but this all the begs the question of you, if you’re an enterprise architect, are you a Technology Adventurer or have you simply become a victim of technology inertia and only know an awful lot about your vertical sliver of a specific layer of what an architected enterprise solution really needs, have you gone the opposite way and actually allowed your specialized expertise to stagnate? What is the opposite of a Technology Adventurer, is it perhaps a Technology Commuter?
http://scn.sap.com/people/clinton.jones2/blog/2010/09/09/is-your-sap-enterprise-architect-a-technology-adventurer
