The fall of the BizTalk Architect – From something abstract to something useful

enfo.fi / enfo.se

The fall of the BizTalk ArchitectFrom something abstract to something useful

May 25th 2015 Mikael Sand

enfo.fi / enfo.seenfo.fi / enfo.se

Who am I?

The fall of the BizTalk Architect

• Mikael Sand• Live just south of Stockholm, Sweden• 40(!)• Senior integration architect and

Azure Associate Enfo Zystems

@mikaelsandmikaelsand.se


Preface



What is important?



What is important in an integration?



What is important in an integration?


• It looks good• It solves a problem• It connects two or more systems• It works• It is reusable


It works



That gives us something to think about



Perspectives


Our usual world view

BizTalk

Salaries

Invoicing

That system

This system

www

Intranet

Shippingpartner

Otherpartner

The place to be

Oh yeah!

BizTalk


How do others view us?


enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #1

You are an expenseLower your expenses




A small business meeting


• 1 employee• 1 meeting room• Some coffee• 5 consultants• 2 hours

• 0 SEK• 0 SEK• 0 SEK• 5 * 870 SEK• * 2• 8 700 SEK / €1 000

enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #2Do not think people are as good at this as you are

Help them understand


Are we the center?



Are we even the center of integration?



Who are involved?


PMCustomerrep

Operationsowner

Enterprice architect

System owner

Application operations

System owner

More PMs

Technicaloperations

The BizTalkArchitect

Developer

Developer End user

Tester

Security


It works


enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #3

Make it work


Perhaps we are not the center of everything




wwwIntranet

CRM SalesCustomer serviceapplication

Business critical ApplicationPrinting Business data



www

Intranet CRM

Sales

Customer serviceapplication

Business critical Application

Printing

Business data


So what are we?



BizTalk Server as a product




Print

BackendWebb BizTalk


Connectors


Just one example


Question


What part of an integration project is the longest?


The preparations


enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #4

Want to be rich and famous? Present a solution, not a problem


So who are we?



Make it work



How?



Structure, architecture andthe right mindset



What do you get?The fall of the BizTalk Architect

• Quick answers to complex problems

• Processes ->• Predictability• Measurability -> • Feedback

• Again: Quick answers• Processes ->• Predictability• Just a little more

concrete

Predictability Business centric


Time for a definition


What is an integration?

enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Roughly the same information is moved from roughly the same system to roughly another system



Information type: Beverages

System A

System B

Beers




System A

System B

Beers

Wine




System A

System B

Beers

Wine

System C

Beers




System A

System B

Beers

Wine

System C

Beers

System D

Empty bottles


Why?



So what is the solution?



The atomic integration


™<-Not really


What is the atomic integration?The fall of the BizTalk Architect

• The integration has to contain all it’s parts and have as few external references as possible.

• The integration will contain everything to be buildable and deployable.

• But: ”Don’t be stupid!”• Duplicate the artifacts and code reusability with copy-

paste• But: ”Don’t be stupid”


The atomic integration gives youThe fall of the BizTalk Architect

• 1 integration• 1 Visual Studio Solution• 1 Application in BizTalk• 1 msi for deployment

• or PS-script, or whatever.• 1 set of documents• 1 common name for the integration (business-IT)• 1 entry in a repository• A very simple solution to a very complex problem


The atomic integration gives youThe fall of the BizTalk Architect

• Easier follow-up• A better fit with Sprints (the Agile method)• A better fit with ITIL since you get a 1 to 1 relationship• Easier add-on development• Easier development over all


The downsidesThe fall of the BizTalk Architect

• May cause large solutions, hard to cooperate within a team.

• Double the info! Then again, gives a nice feeling of control and isolation.

• ESB: Not a perfect fit, might become harder to do. Then again, was ESB ever easy?

• A bit boring


The structure in BizTalkThe fall of the BizTalk Architect

• Integration name: Number + friendly name.• Artefacts: Separated by type name using subfolders

within a project or• One per type, per system.• Orchestrations: Use hard bound ports as standard

and make them shared.• Copy-paste for pipeline components and helper code.

• But: ”Don’t be stupid”.

enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #5

Don’t be stupid


Let me illustrate



The mission






The website

Backend

Printing

INTBUG001.CardTransactions



DecodeJSON Transform Flatten Order

Flat

New cards flat Set name New cards

flat


Stakeholders





Demo


F-ing finally

enfo.fi / enfo.se

Presentation name

enfo.fi / enfo.se

Mikaelism #6Make sure the right error information is sent to the right people in a way the person can understand


The cloud



Azure App Service


Next gen integration



Auth Logging Access Neat stuff Neater stuff Translation

Storage PaymentCaching Facebook Instagram

Backend RegisteryBillingPartner

integratonNew stuff Conversion

Website



What have we learned?



Structurearchitecture

the right mindsetthe atomic integration


enfo.fi / enfo.se

[email protected]

@mikaelsand

mikaelsand.se

Technology

The fall of the BizTalk Architect – From something abstract to something useful