What is the role of an Enterprise Architect in integration?
Integration is place where many project suffer – where many projects fail…
One could say, it’s not EA who should operationally lead the project – but I would say, this is not entirely true… EA is building the guardrails under which projects are being delivered, but E A is supporting key Enterprise initiatives.
So, where is EA in the integration?
If we take a look on TOGAF©, we have EAs in the Business Domain, we have them the Application, Data and Technology domain as well… Where does integration fit in?
It’s an enabler of Business Domain, but not Business Domain, and for sure it’s just Technology Domain… So, it gotta be between Application and Data Domain?
Integration Architecture?
No matter where TOGAF© places integration – it’s up to us to find its place in our Enterprise…
And this place is where? Well, we are witnessing the immense growing complexity of the IT Architecture as a whole – interlacing products & services, we see how much effort (and investment) it really, really takes to run new complex Digital Transformation initiatives (Agile EA – from SOA to Interoperability) – we see a clear need for building the Composable Business (Integration patterns for the Composable Business Architecture)…
The role must be very important… But is it observed like this?
Integration Architecture must be more than Solution Architecture in one product line or in one technology. But is it on the level of Enterprise Architecture?
General perception is – EA is associated with ABBs (Architecture Building Blocks), capabilities and functionalities; while SA is associated with SBBs (Solution Building Blocks), products and components… That leads us to the key question – can we “raise” integrations on the level of ABBs? Or is it only SBBs are talking about?
My thinking…
I’ll go in the reverse order…
If we talk about SBBs – we are in fact talking about products and components which will be used to implement and fulfil business requirements (as per TOGAF© Building Blocks). Also, SBBs are usually Vendor aware.
In practical terms, we may talk about solutions based on specific products, like:
And if we go on the level of components, we can talk about iFlows with or without Datastore or JMS Queues etc.
Now, if we go one level higher in the abstraction, like: Integration flows, API Management, Event Broker, Streaming, Topics & Queues etc. – aren’t we already on the level of capabilities and functionalities which are by definition ABBs? If we talk about specific requirements, like: Idempotent, Serialization, Guaranteed delivery, Publish-Subscribe pattern, Distribution pattern etc.– aren’t we also talking about specific business and/or technical requirements of ABBs (again, as per TOGAF© Building Blocks)?
Summary…
Integration Architecture, as “Domain” (even though it is not observed as such), should be elevated.
In the complex environments, it is not sufficient to observe it only on the perspective of products and components – it should be observed on the level of capabilities, not as a pure technology enabler…
- Different products may be used to build API Management – but in essence no matter which product we use, we actually want API Gateway, API Portal, Developer Hub etc.
- Or, different products could be used to build our EDA (Event-Driven Architecture) approach, but at the end we would always be looking for Publisher-Subscriber pattern, or Async Request-Response patter etc. capabilities.
Composable Integration Architecture?
… Which somehow leads me – why not having Composable Integration Architecture as well? We talk a lot about Composable Business Architecture (What is Composable Architecture?). But if we are building our integration around capabilities, meeting specific requirements, and observing some (preferably) open standards – why not… Why wouldn’t even those integration ABBs or SBBs be our LEGO© blocks we can play around – when we need, or if we need…
Final thoughts
… It is absolutely correct (or even necessary) to have separate EA and SA “layers” of the Integration Architecture, especially when working in the complex environments.
I might be bias, but this is somehow my impression…
Acknowledgment
*) Intro photo by Shubham Dhage on Unsplash