IT architecture
It is hard to conceive a business without IT in some form these days. Overall IT supports the UI, distribution channels, customer service and call center technology, marketing, business logic execution and workflow, business automation, B2B, complex calculations, communications and collaboration, data storage, archiving, document creation and management, decision making, infrastructure management, office automation and their security. Let me list some of the today's Enterprise IT capabilities:
* business and support activities execution (ERP, CRM, SCM, service specific... IT applications)
* business automation through business process & rules engines and workflow replacing repetitive human activities
* storage of structured customer, product, supplier... information
* content management processes such as creation, transformation (paper to digital and vice versa...), storage, archiving, search, publishing and presentation for document, web, media, records...
* identification of customers, partners and employees
* User Interface for documents and processes
* customer distribution channels: web, email, chat
* automated B2B exchange services with partners
* distribution and collaboration services
* communications and mobility: data, voice, video
* data and process integration middleware
* powerful calculations tools for complex algorithms or financial applications
* DW/BI/Dashboards/Risk Management and Roadmapping tools
* decision making tools
* remote access to business processes and data
* office tools for typing, printing, faxing (Office suites)
* drawing and design tools: SDK, RAD, CAD...
* management of all other IT infrastructure
* security (encryption, digital signatures, firewalling...), load ballancing
* the infrastructure to support all above: processing servers, disks, RAID..., archiving tapes ...
The list is still open.
Often not recognised as IT, since there is no human intervention, SW/HW powers real time appliances and machines in the Enterprise manufacturing equipment, robots, SCADA technology, mobile phones...
Since IT has such a high innovation rate, IT may represent a major source of innovation and competitive advantage in the enterprise or, alternatively, when poorly managed, a source of pain and costs.
As the IT complexity and usage grows, Enterprise Architecture, SOA, ITIL frameworks and outsourcing will help you manage the complexity of IT in alignment with the business needs and strategy.
Outsourced, IT will reduce the concern of business people and leave them focus on their own objectives while IT people have the freedom to innovate, architect at will ... with the condition to deliver on time, cost and quality. Both parties are happy as long as the contractual SLA is convenient for both.
...
A traditional business consists of a group of people executing activities aimed to deliver a product by using tools and technologies. Nonetheless, human activities and decisions are increasingly performed by IT systems. Could a business survive without IT these days? What is role of IT now? How much does a business depend on it? This discussion might help explain why typically, it is IT to lead in the development of an Enterprise Architecture.
Nicolas Carr of Harvard, in 2003, has promoted the idea (a very truncated meaning rendered here) that IT, having become a commodity, like electricity, represents no longer a competitive advantage for a business and as such IT investment should be carefully and selectively done - which, for that matter, is not a bad advice for any investment -. Naturally, this was quite debated at the time.
I was and am against it since IT is not a single technology but a complex set in which each technology lives at a different point in its lifecycle, with some IT technologies commoditised and some not yet. And a second argument is that it is not enough to have a technology; one has to master the art or science of management of the technology for best results - like cooking, for instance.
On the other hand we have the privilege of living in the future and as such thinking wisely about the past. These days we can see how everybody tends to outsource everything remotely connected to IT. So far, so good. But we outsource the day to day IT routine operations, that is precisely the commoditised IT Nicolas Carr was talking about; we do not outsource IT architecture, strategy, innovation or emerging technologies.
What we remain with is the IT Architecture and Strategy, e.g. in two words, Enterprise Architecture. And this is where I intended to lead you.
...
I define obsolescence in IT as the state of a system in its lifecycle when it becomes... obsolete - that is old, outmoded, falling into disuse - from a both functional and technological point of view. Given a few years more it becomes an antique and were the system sufficiently rare it will pay you off more than new.
In the business world, there already are a few concepts that help with obsolescence: depreciation of an asset and even amortization in accounting terms. An EA architecture repository and tool should support the obsolescence analysis by adding specific attributes to the metadata of the entity. The EA applications and infrastructure assets may have different obsolescense criteria.
The obsolescence discussion should be had with the business owners using of the application and the IT maintenance teams. All IT assets should have recommended obsolescense periods for planning their replacement. And here I remind you of the concept of value of replacement in the insurance industry.
Obsolescense from a business perspective:
the service (delivered by IT systems) is not competitive or not making profit any longer
the service logic needs significant updates (legislation changes, compliance ...)
the User Interface has to be significantly upgraded
competitors grabbed an edge with new technology features, need to offer similar or better
Technology obsolescense causes:
technical skills no longer available or becoming too expensive
the scalability has reached its limits
the architecture is harder and harder to maintain, too many patches
asset already depreciated
...
As a result of an obsolescence analysis a number of "standard" measures can be adopted. The analysis should also document the cost of replacement in an attribute and time frame of obsolescense.
remove, no replacement
replace with newer technology
upgrade
wrap application, virtualize technology to extend life
...
Obsolescence should be included in your Enterprise transformation roadmap and projects portfolio.
...
Enterprise Architecture currently and mostly equals IT. With a growing emphasis on business architecture, a question was raised in various fora: how to differentiate it from the existing EA profession and practitioners which mainly deliver IT architecture but promise the goods of, at least, a business architecture. As expectations are not met, the image of EA is tarnished.
IT does its best to provide an IT EA, given the fact that there is no business picture the IT systems can be aligned to. For IT, the business architecture is a departure from the IT job description.
The existing EA IT architects are keen though to move into the business architecture space. And that is not too difficult as long as there is demand, there is no specific body of BA knowledge and no selection criteria for a business architect. I've already seen ads for business architects requiring TOGAF certification, which is essentially IT. Many EArchitects are claiming the business domain by throwing around a few notions like capabilities, process and strategy.
The issue is that the rather new breed of Business Architects would like to differentiate themselves and call themselves otherwise from the existing EA (IT) architects and the current not quite flattering EA image which did not deliver on its promise, lessening its credibility.
But IT architecture is a part of Enterprise Architecture. So are the organization or people and the non-IT technology architecture, seldom covered today, if at all.
The business architecture is the top layer of the stack, as we know, and most important because it shapes them all. Without a business architecture current EA (IT) attempts fail because the IT systems picture does not convey the structure or operation of the Enterprise.
To me, the EA name is relevant. The EA must be seen in its whole, including business, IT, organization... If we change the name of Enterprise Business Architecture to anything new, and leave the EA name to IT, we severe the link to the complete EA framework and we create competition with the EA architects from the IT space attempting to cover the whole EA.
I don't think we need a new name for EA. We just need to qualify the architect title with the EA domain we work in, emphasize the specializations (Enterprise Business/Applications/Infrastructure... architect and also the generalist EArchitect or the Chief EArchitect, covering it all).
But how can one stop the flood of imposture without a decent body of knowledge and selection criteria for an EA business architect (or even for an Enterprise IT architect)? No matter the name, the profession can be easily hijacked. I don't think certification for the current frameworks is an answer, as many new organizations appear to propose, for the simple reason that certification has to be done against a body of knowledge.
The business architecture body of knowledge is scattered and architecture is not a term in the business vocabulary. Without an agreed framework, the BA will fail to produce the goods.
The E Business Architecture is also claimed by the BPM domain.
To defeat the current scepticim about EA, we have to produce though the overall Enterprise architecture so that the technology and organization align to business operation. For that we have to define what business architecture is, what are its artefacts...
...
It depends on viepoint. But it is mostly IT today although, more and more people would like the EA to cover the whole Enterprise.
EA is an IT term. It initially came from Zachman. Then it was adopted by the IT community in branding their technologies Enterprise wide: Enterprise Java, EAI, ESB... So why not Enterprise (wide) Architecture? Well, there is no "IT" in the name because it looked evident to them.
The role called Enterprise (Java) Architect has also been introduced by IT to denote an expert programmer that was able to design SW on top of complex application packages and their many many interfaces, like Java, .Net. But this adds to the confusion reigning today, about EA. Many still think of EA in terms of software.
It is likely that the term architecture, borrowed from the construction industry, came from IT system design, where the diagram of the logical system blocks and and their interconnections was coined architecture.
The business vocabulary does not have an architecture term. There is no concept of architecture in the business domain, in my opinion. Business uses Value Chains, business models, process maps...
So the EA concept comes from IT. More, the design methods come from IT: structure analysis, OO... IT can do architecture work but it can hardly do EA without business knowledge and a business architecture. EA is mainly designed by IT for IT.
EA has a high penetration though; its potential was understood by business due to the promise in the name. Still, it delivers little, since most people have to work out first what that is, then its scope, what framework to use etc. The Enterprise specific work is only done after that.
So EA is an IT term, but with a great promise that does not escape the business people. As such it was also adopted in the larger business context of the Enterprise.
Business Architecture and BPM are part of the EA (taken in the context of the Enterprise rather than IT alone). Zachman's matrix proves this and I guess we all know it.
EA, as a term, is too good to be abandoned to IT, I believe. Anyway it would be hard to abandon the name in practice. "EA" is currently used without qualification and discussions always arise on the surrounding scope. We should qualify EA with: Enterprise IT architecture, Enterprise Business Architecture, Enterprise people architecture... Business, IT, People are in fact layers in most EA frameworks.
EA, ultimately, should become, from an IT centric activity, a coordinated set of various business activities: IT, BPM, Six Sigma, organization design... IT cannot really cover alone business processes for instance. Business knows them best and analysts do it. Six Sigma would look into processes IT would not care about because they are performed by humans. Organization design and alignment to business architecture should be another EA activity done by business.
The Chief EA architect should report high up and coordinate all EA related activities like BPM, Six Sigma, IT architecture, alignment of technology to business and strategy...
I gave a similar answer to a discussion on this topic running in a Linkedin EA network group.