When an organization undertakes a major Information Technology project, most executives, managers, and project sponsors overlook an important component in the total cost of ownership equation; “maintenance and enhancements“. I am not referring to software, hardware, and cloud hosting maintenance fees. When capitalized dollars are used as the funding source for the project, due diligence is given to these items as these costs are folded into the depreciation schedule associated with the endeavor. I am referring to the steady state costs. Based on the architecture and design patterns employed in the project, what are the future carrying expenses as enhancements and maintenance activities are performed?
It appears there is a new quest for the holy grail in Master Data Management; autonomous processing. The hypothesis is simple. Given the proper set of business rules, robust master data management algorithms, and machine learning applications, the need for human review and intervention can be eliminated from the Data Stewardship process. I would argue not so fast. For the foreseeable future, there will always be the need for manual stewardship. While the new breed of technologies should reduce the length of exception queue, nonetheless the queue will continue to exist. Manual data stewardship drives quality assurance. The data stewardship exception queue requires manual review
There has been a lot of chatter lately on the various forums discussing the merits of an architect. Specifically, the question being raised have architects out lived their usefulness? I for one see the use of the term Architect overused. Hence thats why there is an emerging movement for an adoption of industry standards and certification. There are specialists within the domain of Information Technology. I would assert that people who specialize in enterprise class data modeling and infrastructure should be considered architects. Vendors, however, who want to impress their prospective clients with the notion that members of their pre-sales team are solution architects, I mean really.
Too often in today’s Information Technology world, practitioners are categorized into silos. The common argument for the classification is that the technology is too complex and no one individual can possibly be the master of it all. While there is some truth to that statement, there is no doubt in my mind that an Enterprise Architect can be a generalist across multiple functional and technical subject areas. Consider the example of the modern ERP application. Regardless of the brand; SAP, PeopleSoft, Siebel, Oracle’s e-Business Suite, etc. all the major system integrators align their resources into the two camps; Technical and Functional. It is my opinion, that